This article has a bit of a false dichotomy for why reified generics we’re not possible. It says roughly:
1. We must make the existing ArrayList become a generic type.
2. If Java’s generic system was reified, that would be a backwards incompatible change.
3. Therefore reified generics are not possible to implement in a backwards compatible way.
Ok, sure, but if you instead a new generic collection types and leave the old ones alone, you don’t have to worry about breaking existing compiled code.
This comment about C# suggests a lack of familiarity with the approach C# took:
> C# made the opposite choice — to update their VM, and invalidate their existing libraries and all the user code that dependend on it.
All of the pre-generic C# libraries continue to exist to this day (ArrayList, HashTable, and the non-generic IEnumerable). Applications that used them never stopped working. New code uses the generic collections (List<T> and Dictionary<TKey, TValue>).
Anyways, I think the costs that Java is currently paying for non-reified generics (reflection, performance, and type safety mentioned in the article) is not worth the backwards comparability with the 20 year old J2SE 1.4. The price C# pays for making a backwards incompatible generics (mostly some minor annoyance when designing a collection class implementing IEnumerable) is worth it at this point.
Java generics has got to be the least bang for the most buck in the entire history of programming languages.
Turning the once clear API documentation of the entire standard library into an incomprehensible mess, for what? So you can avoid casting when getting something out of a collection?
So no, absolutely not. Enough with generics. It was a mistake in the first place. Don't dig any deeper in that hole.
2 comments
[ 2.8 ms ] story [ 12.7 ms ] thread1. We must make the existing ArrayList become a generic type. 2. If Java’s generic system was reified, that would be a backwards incompatible change. 3. Therefore reified generics are not possible to implement in a backwards compatible way.
Ok, sure, but if you instead a new generic collection types and leave the old ones alone, you don’t have to worry about breaking existing compiled code.
This comment about C# suggests a lack of familiarity with the approach C# took:
> C# made the opposite choice — to update their VM, and invalidate their existing libraries and all the user code that dependend on it.
All of the pre-generic C# libraries continue to exist to this day (ArrayList, HashTable, and the non-generic IEnumerable). Applications that used them never stopped working. New code uses the generic collections (List<T> and Dictionary<TKey, TValue>).
Anyways, I think the costs that Java is currently paying for non-reified generics (reflection, performance, and type safety mentioned in the article) is not worth the backwards comparability with the 20 year old J2SE 1.4. The price C# pays for making a backwards incompatible generics (mostly some minor annoyance when designing a collection class implementing IEnumerable) is worth it at this point.
P.S. ok, I do admit that C# forking the collection library is still causing ongoing maintenance work 18 years later: https://github.com/dotnet/winforms/pull/8673
Turning the once clear API documentation of the entire standard library into an incomprehensible mess, for what? So you can avoid casting when getting something out of a collection?
So no, absolutely not. Enough with generics. It was a mistake in the first place. Don't dig any deeper in that hole.