Java 5 vs. .NET 2.0 generics: past vs. future

There is a thing that struck me out about Java 5 vs. .NET 2.0 generics.

Major design constraint for the generics in Java 5 was the backward compatibility. Much of the statically available information related to generics is not retained in the byte code. It is erased during a compilation process. The generics become sort of consistent with the rest of the language. There is even ability to retrofit old API to the new language features as it could be seen from the collection framework.

As result, the generics in Java 5 cause a kind of "fake" feeling. There are a lot of things that cannot be done using Java 5 generics which are desirable. For example, a instance of a generic class cannot learn about arguments with which it was created. Some awkward constructs like "((ArrayList<String>)(Object)(new ArrayList<Integer>())).add("Test")" do not create a runtime exception (the compiler honestly warns that there might be a problem).

However by doing so, Java was positioned as a "legacy" language where the burden of the past outweights needs of the future development.

In .NET 2.0, the generics were added as a new feature. It looks like the backward compatibility was not a major constraint during the development. It is a bit facilitated since new collections also implement untyped collections interfaces. However unlike Java 5 counterparts, .NET 2.0 generics do need invoking the backward compatibility argument for explaining weird features. They are much cleaner. So generics in .NET 2.0 looks like mostly motivated by their future use.

On other hand, it is puzzle to me why generics did not make into .NET 1.0. Lack of generics was well documented problem of Java. And .NET framework IS primarily inspired by Java (it was quite funny to read some MS documents that discuss C# and very carefully avoid mentioning Java and mentioning such remote languages as as C). And many fundamental Java language problems were fixed in .NET. This one belongs exquisite group of language problems that .NET designers chosen to reproduce. I kinda understand time-to-market arguments. But I do not believe that few additional months would have made a difference here. Many Java proposals for generics were on the table for long time, and it was possible to select a good one from the start. At least it would have saved them from the shame of CodeDom API.

So it looks like Java position itself as legacy language and .NET as an actively developed language runtime. It might be explained by the fact that the Java had much longer past than .NET. However it does not bode well for Java future. This is a possible reason why Sun started development of the new language called Fortress instead of adding needed features to Java. Open sourcing Java might break this self-image problem and cause implementing and trying more daring features in Java language, but I would not bet on it.