The Race Is On
by Ted Neward
<Your Quote Here>
Generics represent a powerful way of examining and modeling system behavior--Ada first introduced them, and C++ (under the guise of "templates") gave them widespread exposure. In many ways, generics/templates offer the O-O programmer a first look at what "metaobject" programming, MOP models, Aspect-Oriented Programming, and other approaches "above objects" are like. This is powerful, powerful stuff, and it's great to see movement from both the major technology camps (Java and .NET) on this score.
But I'm starting to get just a wee bit worried here. Java had the better part of a three- to four-year lead on Microsoft to introduce generics into the language and platform, and while we can't say that Microsoft has "passed" Java on this score--both technologies are in a form of beta, after all, neither being a part of the corresponding "commercial" product--Java's JSR on generics has languished behind the JCP for the better part of a year now. What's taking so long?
The Curse of Success
While I can't speak with any authority, one of the thoughts that comes to mind is that Sun is perhaps becoming a victim of its own success on this score. In particular, there seems to be a general trend within the JCP to "not change anything" at the bytecode level. The language itself may be open to (select) change, such as the welcome addition of assertions in JDK 1.4, but the bytecode set remains precisely the same as it was when JDK 1.0 shipped. (Certainly no new opcodes have been documented in the JVM Spec, nor are any new ones showing up in my semi-frequent trips into javap.) In fact, the generics implementation put forth by Sun a year ago was a language-level implementation, essentially generating "standard" Java classes out of the genericized Java language. This is in contrast to Microsoft's approach, which modified the IL instruction set to cope with the new requirements of generics.
Part of this differential stems from the fact that .NET is multilinguistic, and Java is not; .NET generics, in order to be successful, will need to be consumable from any CLI-compliant language (imagine JScript using generics!), whereas Sun has never really embraced the idea of any other language as a front-end to Java bytecode. This simplifies the Java platform somewhat, but also limits it--whether this is a good thing or a bad thing is still open to interpretation.
What bothers me, though, is that there really doesn't need to be this resistance to changes at the bytecode set level within the JVM. Every release of the JDK has upped the version numbers embedded in a .class file, and older VMs can't run .class files with higher version numbers than they recognize. Since the versioning scheme is already there, and VMs use it, why not be a bit more liberal with extending and expanding the bytecode set, and bring some of this new functionality into Java? This kind of forward-thinking will help Java compete with a platform that's brand-new and doesn't carry some of the weight of a 6-year history.
On Your Marks...
In the meantime, however, it's a race. Both Microsoft and Sun have heard that generics are something developers want (even if it was those same developers that fled C++ because "templates were too hard"), and whomever gets generics into the commercial release of their platform gains some major PR points and developer mojo. In the end, though, if both bring generics support into their platform within three months of each other, it'll be a push. The only thing that would really hurt anybody is if one platform got them, and the other one didn't for six months or more.
Frankly, I'm excited for *both* platforms. This is why competition is good.
Generics in Java
As I understand it the method chosen for implementing generics in Java involved no byte code changes. The compiler checks the declarations made in the program to ensure types matched and then "inserted" the correct class casts transparently. For example GJ [http://www.cis.unisa.edu.au/~pizza/gj/] emitts standard byte code.
The Java Generics JSR 14 includes a fairly comprehensive spec and a link to a prototype (that requires the 1.4 JVM). You can start by downloading the public review here .