No-one can deny that in the last few years, Java development tools have become much better. The three main Java IDEs are Eclipse JDT, IntelliJ IDEA and NetBeans (as well as Eclipse JDT-derivatives). The competition between them has resulted in major advances; IntelliJ IDEA, as the commercial heavyweight, has had to innovate to justify its price (and by all accounts, well worth the money) -- but Eclipse and NetBeans have been snapping at its heels (and of course, each others'). Other non-Java development tools haven't tended to improve as quickly over the years, pretty much due to a lack of competition.

But at some point, competition for the sake of it becomes re-hashing old ideas, and often in a less constructive way. For example, Sun relatively recently added the java.util.logging API, which is seen as inferior by many to the de-facto Log4J. One of the main problems with introducing it as a core library is that it's not available on older VMs. (I have a separate beef about the problems with bundling core libraries as part of the JVM; but that's not the point of this entry.) From all accounts, it was seen as Sun with Not Invented Here syndrome, needing to roll out their own.

More recently, Sun have released an early draft of JSR 277 for modularising JARs. The goal is to provide versioned dependencies between JARs and to treat JARs as modules (by providing extra meta information in the JAR itself, computed from annotations in Java code). It seems to be quite closely related to JSR 294 in that both deal with modularisation of Java modules; but seems to require additional changes to bytecode to make it happen, and as such, it will only be available from Java 7.0 (or J2SEv7 or Java JDK 7.0.1_b42 or whatever it will end up being called ). As Elliotte Rusty Harold put it: "if inner classes and generics did not require VM level changes, this proportionately smaller change shouldn't either?"

Peter Kriens (of the OSGi Alliance ) is also less positive about JSR 277. (Perhaps that isn't too surprising; the OSGi framework is submitted as JSR 291 ; however, the OSGi framework is actually being used by millions of people right now, whereas JSR 277 is still in early review form.)

What's particularly amusing is that the JSR has a section entitled "Why isn't this need met by existing specifications?", in which they try and justify the reasons why OSGi isn't sufficient ... amongst other things: "Because the versioning semantics in the OSGi framework is simplistic, it is not a sufficient solution to address the JAR referencing problem." Of course, the ironic thing here is that the OSGi versioning is both well defined, and can have abitrary fixed versions, or ranges (with either open or closed ends). The JSR 277 defines versions by using 1.1* or 1.1+. Care to guess what those mean? The first means anything from 1.1 to 1.999; the second means 1.1 to 9999.99999. These are relatively easily explained using the (well-known) mathematical notation that OSGi adopts, using [1,2) or 1 respectively. So it seems the argument about versioning is fallacious at best; unlike well understood mathematical intervals, they've chosen to come up with their own variants that isn't easily capable of representing ranges like [1,5).

Also, the versions are specified as 1.2.3.4.qualifier. I'm not really sure why people need that many numbers; there seems to be enough difficulty with the third digit as is in Eclipse, let alone adding a new level for no particular reason. However, one nice part is that 1.2.3.4.qualifier is seen as less than 1.2.3.4; presumably, with the idea that people will release 1.2.3.4.beta1, 1.2.3.4.releasecandidate2 etc. all of which will seem as less than the final 1.2.3.4 when it's released. It's almost a shame that this idea wasn't mooted with the original OSGi stuff; but it's a bit of an assumption about what you're going to use the versioning for.

I think Peter sums it up best at the end of his blog:

"The only way this EG can pass its final review is lack of attention for detail of the Executive Committee or alternatively, serious muscle power of SUN. JSR 277 is a missed opportunity for Java. I do not doubt that this specification will end up in Java 7, but it will further fragment the Java world for no technical reason."