4 ms·

I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java

I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. The fact that C# generics are understood by all parts of the .NET ecosystem makes it so much better and boosts the language to a much higher level than Java. C# and Java always seemed to be roughly the same to me until C# got generics, and that boosted C# to a much better plane of existence, which was followed by a great deal of innovation such as LINQ, async-await, lambdas, etc, all of which benefit from C# generics.

xenadu02 9y ago
To answer the parent's question: Yes, it was necessary. Doing it the way they did allowed source compatibility with pre-generic or non-generic-aware code. Passing a List<string> to something that expects an IEnumerable works just fine and effectively gives you the Java solution (at a source level) when talking to older APIs! This is why interface IEnumerable<T>: IEnumerable. >I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. It is worse than that. Java generics don't work with value types at all thanks to this. A C# List<int> is much closer to a zero-overhead abstraction. It does not box the primitive int values. If Java ever adopts primitive generic types it will break compatibility or introduce massive performance overhead, as touching any non-generic API forces a boxing conversion. Either it negates the reason for type-erasing originally or it eliminates the main benefit of non-boxing value type support (performance). (I should clarify that Java doesn't have first-class value type support either so this really only applies to primitives) >I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. It was a deliberate design decision to retain compatibility between pre-generic and post-generic Java code. Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. It was also clear back then that Java would exist for far longer with generics than without and that far more code would be written in Java post-generics than pre-generics. The result is everyone who uses Java is stuck with limitations and negative performance impacts forever, rather than accepting some short-term pain. It is also my personal opinion that source compatibility is what developers actually cared about and Sun should have told the stodgy risk-averse big Java houses to suck it up and get ready for JVM v2. It would have been a good opportunity to fix a few other things in the JVM. C# had the benefit of hindsight in some ways. I'm not sure if Java demonstrates how open delivers inferior results, how bad leadership can impact a project, or just what happens if you pay attention to what "enterprise" customers claim they want.
- sebazzz 9y ago
  > Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. Yes, but from a marketing perspective breaking with the past is usually not desired. Especially if your product is currently being adopted and is already partially adopted in both hardware and software (which might have been the case when they implemented generics?).
kevin_thibedeau 9y ago
The Java implementation is a workaround to avoid breaking processors that executed Java bytecode. ARM Cortex can still theoretically do it, though it now just traps into a soft VM.

xenadu02 9y ago

To answer the parent's question: Yes, it was necessary. Doing it the way they did allowed source compatibility with pre-generic or non-generic-aware code. Passing a List<string> to something that expects an IEnumerable works just fine and effectively gives you the Java solution (at a source level) when talking to older APIs! This is why interface IEnumerable<T>: IEnumerable. >I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. It is worse than that. Java generics don't work with value types at all thanks to this. A C# List<int> is much closer to a zero-overhead abstraction. It does not box the primitive int values. If Java ever adopts primitive generic types it will break compatibility or introduce massive performance overhead, as touching any non-generic API forces a boxing conversion. Either it negates the reason for type-erasing originally or it eliminates the main benefit of non-boxing value type support (performance). (I should clarify that Java doesn't have first-class value type support either so this really only applies to primitives) >I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. It was a deliberate design decision to retain compatibility between pre-generic and post-generic Java code. Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. It was also clear back then that Java would exist for far longer with generics than without and that far more code would be written in Java post-generics than pre-generics. The result is everyone who uses Java is stuck with limitations and negative performance impacts forever, rather than accepting some short-term pain. It is also my personal opinion that source compatibility is what developers actually cared about and Sun should have told the stodgy risk-averse big Java houses to suck it up and get ready for JVM v2. It would have been a good opportunity to fix a few other things in the JVM. C# had the benefit of hindsight in some ways. I'm not sure if Java demonstrates how open delivers inferior results, how bad leadership can impact a project, or just what happens if you pay attention to what "enterprise" customers claim they want.

sebazzz 9y ago
> Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. Yes, but from a marketing perspective breaking with the past is usually not desired. Especially if your product is currently being adopted and is already partially adopted in both hardware and software (which might have been the case when they implemented generics?).

kevin_thibedeau 9y ago

The Java implementation is a workaround to avoid breaking processors that executed Java bytecode. ARM Cortex can still theoretically do it, though it now just traps into a soft VM.