Java Generics

Responding to my last post on using my experience with generics in Whidbey, one Java enthusiast comments:

It is interesting that in .NET Generics tie you to the release date of the runtime but in the Java world the release of Generics with 1.5 will not impact what runtimes you can run on because it is implemented as a compiler feature. Being biased to the Java side of things I prefer the byte code compatibility of the Java world.

The issue with byte code compatibility is not as important in .NET world as in Java, since application vendors currently are expected to install the .NET redistributable with their application. On the other hand, version 1.1 is already installed on 70 million Windows machine through prior installations of existing .NET applications or Windows Update. Relying on the Whidbey runtime instead of Everett (v1.1) does introduce more friction as Whidbey is less likely to have been previously installed than Everett. After Longhorn, which will ships with a standard runtime, compatibility will become more important.

My initial reaction with the implementation of Java generics in the Tiger release was negative. That implementation preserves byte code compatibility at the expense of performance. In particular, primitive types are boxed rather than stored natively in Java's generic collection.

I naturally regarded it as another example of Java having lost its techological leadership. But, after thinking about this, and using generics, I suspect that the reality is quite different.

 Sun is full of smart developers and it was probably the best decision to be made. Had I been in their shoes, I may have made the same decision. Nothing in the design precludes Java from introducing a more performant implementation in a future VM, and at the same time generics will still have downlevel support in the current VM. There are also real performance improvements from Java's Tiger implementation: Reference types, unlike primitive type, should behaved as optimally as in the .NET world, as the main cost, that of casting, is eliminated in both implementations.

 

Comments

[Joe Cheng]

Personally I'm glad Microsoft is evolving the .NET platform so aggressively. Now is the time to do it, while the platform is young and the burden of backward compatibility is (relatively) small. And thank goodness .NET has a pretty good side-by-side versioning story (version of the runtime/libs, that is), unlike Java.

[Sean McLeod]

I was also under the impression that Java 1.5 generic code would run on an unmodified JVM. However according to the following post from someone who went to the recent JavaOne conference Java generics do require a modified JVM. The aim it appears was to make the number and size of changes required to modify the JVM to a minimum as opposed to zero changes.

http://weblogs.asp.net/ericgu/archive/2004/06/29/169359.aspx

"As others noted in comments to my last post, if you use 1.5 features, you have to run on a 1.5 VM. So apparently the goal was to keep VM changes to a minimum rather than having no changes. I can understand not wanting to require all JVM writers to have to make big changes to support generics."