You know, like the CLR does. Is anyone even admitting the lack of runtime generic information is a problem, and working to solve it?
+3
A:
The designers of Java opted for this solution to maintain backward compatibility (on the bytecode level). Since then, there is even more Java code out there, thus breaking backward compatibility would have ever worse consequences. So I doubt they would change their minds about this.
Péter Török
2010-10-22 15:46:39
They have mentioned that they'd like to do this in the future if possible, and aioobe mentions that there may be a way to do it without breaking backward compatibility so... I don't think it can be ruled out.
ColinD
2010-10-22 15:51:38
@ColinD, nothing can be ruled out of course :-) Note that @aioobe's quote proposes type reification as an _optional_ feature (supposedly for new code only).
Péter Török
2010-10-22 16:04:08
@Peter the CLR didn't suffer any backwards compatibility issues when generics were implemented in .NET 2.0... what makes the JVM more problematic in this regard?
Stephen Swensen
2010-10-22 17:26:58
@Stephen, from what little I know about the CLR, there the same APIs are offered in both legacy and generic version; in Java (according to _Java Generics and Collecetions_) it was feared that this could lead to a versioning nightmare when many different APIs and libraries are involved.
Péter Török
2010-10-22 20:28:14
@Peter, ah, I see. That's interesting, a colleague of mine with a PhD in computer science was commenting on how he thought having one type, for example List, which can be used both in its generic or non-generic form was confusing, and was intrigued when I told him .NET created a whole separate namespace for generic types (in fact, they had to, List<int> and List<string> are completely different types, for example... except they both implement the non-generic IEnumerable interface, one way .NET dealt with compatibility I suppose).
Stephen Swensen
2010-10-22 21:02:48
@Peter, in practice, I don't think the .NET community suffered from "versioning nightmares" due to the split legacy / generic APIs. When you encounter an API which uses non-generic classes, it's just a "shucks" moment. Whereas coming from .NET and working with Java for the past year I have experienced a whole lot of "WTF" moments when dealing with non-reified generics.
Stephen Swensen
2010-10-22 21:08:53
@Stephen, yes, it can be a problem in certain situations. And judging from the number of related questions on SO, it is quite confusing.
Péter Török
2010-10-22 21:25:48
+1
A:
I believe someone (possibly Mark Reinhold) said at JavaOne this year that they may try to reify generics in Java in the future. This certainly wouldn't be any sooner than Java 9 though, and would be a huge change with a lot of potential issues to be worked out.
ColinD
2010-10-22 15:49:55
A:
The problem can be partially solved without JVM changes: In Scala (running as well on the JVM) you can add so-called Manifests which hold run-time type information for generic parameters. I think this solution could be adapted for Java without too much trouble. It isn't perfect, but probably much easier to implement as "the real thing".
Landei
2010-10-22 19:13:12