JSR 291 rubber-stamp?

My colleague Jim Colson was interviewed by SD Times for the article "OSGi, JCP Tussle Over Component Support in Java: Critics decry effort as a rubber-stamp move".

The piece notes that JSR 291 is an additional source of requirements for OSGi, but doesn't go into specifics. It ends by quoting Hani Suleiman as saying "I was told that this is in fact a rubber-stamping effort and that the OSGi spec will not change".

So is this just a matter of hearsay and opinion or are there some relevant facts? Did the OSGi specification pop out of JSR 291 without any input from the Expert Group?

Well a number of specific requirements were raised by the JSR 291 Expert Group and resulted in changes in the underlying OSGi specification.

Take a specific example of a non-rubber-stamp change: the addition of an API to enable declarative service support and other similar features to obtain the Bundle context of a specific bundle.

This requirement was initially raised by BEA on the JSR 291 Expert Group mailing list as part of a thread relating to SPIs. (I'm glad we decided to run the Expert Group mailing list in the open!)

Since then the new Bundle.getBundleContext method has appeared in the early draft and public review draft specifications and in the Equinox open source reference implementation.

Does that seem like rubber-stamping to you?

What's the point of JSR 291?

It seemed time to re-iterate the reasoning behind JSR 291. For example, Sun's recent voting comment showed they apparently still don't understand what the JSR's there for.

Adoption
There's a ton¹ of software already built on top of OSGi and it keeps increasing. Since this is mostly Java code, the JCP ought to take notice, and sooner rather than later.

Familiarity
As Sun point out, the specification and its expert group already exist thanks to the OSGi Alliance, so what could standardisation in the JCP possibly add?

Well, there are benefits to the JCP and to OSGi. The Java community gets access to the specification, RI, and TCK in the familiar, JCP-standard way. OSGi gets another source of requirements, continuing its tradition of engaging with current and potential users.

Compatibility with Java ME
JSR 232 does a similar job to JSR 291, but for Java ME. Having a consistent, compatible dynamic component system across Java SE and Java ME is a no-brainer.

Footnote:
1. Although good project managers use KLOCs only in joking terms these days, no better metric has gained universal acceptance. The 'ton' is a strong contender as it refers to the mass of software, rather than its volume. 'kiloton' and 'megaton' are useful for larger software projects, especially in the defence sector.