JSR 291 Approved

Yes! JSR 291 Dynamic Component Support for JavaTM SE has been approved by the JCP Executive Committee with a wide margin! Only Sun Microsystems, Google, JBoss, and Hani Suleiman voted no (out of 16 votes). The EG will have an open mailing list so please tune in.

What were the objections to this JSR? Reading the comments, it seems that some people feel the JCP process is abused by rubberstamping a specification that was not invented in the JCP. JBoss says:

We fail to see the need for this work to be rubberstamped within the JCP process. If it cannot be simply referenced by some other JSR, then it's relevancy is immediately called into question. If the OSGi work is sufficiently well formed that no further input is required by JCP members, then why not have a 2 page JSR that simply says "Go to the OGSi site if you need this capability". If it really requires a more indepth specification, then we should be allowed to modify the work as it progresses through JCP.

A similar discussion took place on the jcp-open@apache.org mailing list during the running-up for the vote (Apache voted yes):

I think that is a problem. Where is the community in a rubber stamping process? It just seems counter to open source and I'm not sure we want to support such specs.

Is JCP a design body or something else? Does the average Java developer care if JCP designs the standard? The power of the JCP is that the Java community uses it as a reference for Java technology. Using technology from JSRs means that you are more likely to use mainstream technology than using a standard from some lesser known club. However, actual design work in the JCP is not a prerequisite to achieve this goal. On the contrary, using existing specifications that are not covered by any of the JSRs can speed up the development of crucial specifications. For example, the features that the OSGi specifications provide are way overdue in Java. Not only are they urgently needed to create a bridge between the J2ME and JSE worlds, they also provide a deployment model that works for libraries and applications, and last but not least, enable aggressive static and dynamic optimizations during JITting.

So far, I have not seen any technical objections against the OSGi specification in any of the discussions. The most negative I have heard is that starting from scratch is better to not have any legacy to take into account (without detailing the legacy issues).

Is it likely that starting from scratch will create a much better specification? The OSGi specifications have taken 8 years of intense development and feedback, matching that kind of development effort is no panacea. In one mail it was suggested the OSGi had just put together some 9-5 programmers that only created some paper documents, which is a very false picture. We?ve had RIs and TCKs from the start, they are mandated by the OSGi rules.

All this does not mean that there are no possible improvements, humans are not perfect and the world does not stand still. However, it is highly unlikely that a magnitude of improvement can be achieved with a brand new design. A brand new design will require a learning curve to achieve the maturity the OSGi specifications already have, which will take a lot of time. Also the compatibility between J2ME and JSE is at stake. The OSGi specifications run on every Java VM from 1.1 to 1.6; if JSR 277 makes language changes, it is very unlikely that such a change will be useful in J2ME for the next decade.

Java has a tremendous opportunity to play a significant role in the explosion of connected devices as well as in the server market. However, for this to happen, it must be possible to run the same middleware on many different devices: from servers to phones. Strong modularity is crucial for this to happen. The OSGi can provide a huge missing part of the overall puzzle.

Peter Kriens

posted by Peter @ Tuesday, March 14, 2006