Unfortunately I cannot figure out exactly why they've chosen the current solution. To me there seems to be some conflicts between te jsr 14 goals and the current public draft that is available for this jsr 14. The goals seem more ambitious to me. Most decisions are based on the huge amount of legacy code for the Java Platform or problems related to modification of the JVM. Therefore I think it was a huge mistake not to include .NET generics in the first release of .NET.
public draft of jsr 14:
The proposed extension is designed to be fully backwards compatible with the current language, making the transition from non-generic to generic programming very easy. In particular, one can retrofit existing library classes with generic interfaces without changing their code.
In essence this means that you can use existing libraries as if they where parameterized. Although I understand the goals, I think this sucks. A class is parameterized or a class is not parameterized. The result of this goal is illustrated by the early access compiler that is available: you have to compile against 'stubs' for the Java Collections. These classes do not contain an implementation. At runtime the current, not parameterized, classes can be used. Of course this is great at the moment because you can use generics without requiring a new JVM, but is it worth it?
Some goals of the JSR:
G4) Simplicity. Keep it simple for users, but not necessarily for implementors: It's okay to place a larger burden upon VM and compiler implementors (within reason) if that will make generics more natural and easy to use.
Well, that sounds good to me. Now hope that they will bring this into practice.
G7) First class generics. Types involving parameters should be first-class types. This goal consists of several subsidiary goals:
a) Instantiated parameterized types (e.g., List) should be
b) Type parameters (e.g., T) should be first-class types.
(A consequence of this is that List is a first class type).<br/>
By "first-class" we mean that these new sorts of type expressions can be
used in exactly the same ways as existing type expressions. In particular,
it should be possible to cast a value expression to one of these sorts of
types, and to test whether an object is an instance of such a type.
I doubt whether this goal is completely satisfied by the current proposal. If the types are really first class, I would expect to be able to create a new instance of this type or pass the class to some method, which is not possible.
public draft: To facilitate interfacing with non-generic legacy code, it is also possible to use as a type the erasure of a parameterized class without its parameters. Such a type is called a raw type. Variables of a raw type can be assigned from values of any of the type's parametric instances. For instance, it is possible to assign a Vector<String> to a Vector. The reverse assignment from Vector to Vector<String> is unsafe from the standpoint of the generic semantics (since the vector might have had a different element type), but is still permitted in order to enable interfacing with legacy code. In this case, a compiler will issue a warning message that the assignment is deprecated.
Maybe great from the practical point of view: interaction with legacy code is possible, but imho this really sucks from a formal point of view.
NextGen is somewhat better. There are rumours that Java generics will be extended to NextGen in a future more complete revision of the Java Platform. I doubt whether this two fase introduction of generics is a good idea.
NextGen is a more ambitious extension of Java, based on the same source language as GJ, developed by Cartwright and Steele that overcomes the limitations of GJ by introducing a separate Java class for each distinct instantiation of a generic type; all generic type information is preserved by the compiler and is available at run-time. Hence, type dependent operations are fully supported by NextGen. On the other hand, NextGen retains essentially the same level of compatibility with legacy code as GJ. For these reasons, we believe that NextGen could serve as the basis for an important step forward in the evolution of the Java programming language.
A few more links that might be interesting:
Java Generics report.
There is also a presentation on generics for .NET that compares the approach chosen by .NET with the various proposals for Java. You can find some links at my overview of .NET resources. There is also a link to a paper.
(sorry for the long message ;) )