The Java Community Process
(JCP) Executive Committee has voted on the final public review of Java Specification Request (JSR) 291
; The Specification for Dynamic Component Support. What makes the JSR different, aside from the technical details, is the core of the proposal is contained in a document that is not controlled by the JCP.
Of the 16 member committee, 9 voted yes, 2 voted no, and 1 abstained. Voting no was Sun Microsystems and Hani Suleiman. Though both parties had no specific complaints about the technology, they both complained that this JSR was nothing more than a pass through to the OSGi
specification. From Sun we have the comment;
Sun is still unclear as to the purpose of this JSR and the role of its expert group in the JCP. There appears to be no need for this JSR as the OSGi specification and its working group already exist
The comment continues with; Sun is interested in "cleanly accommodating current custom classloading based solutions such as OSGi in JSR 277
Hani Suliman agreed with this position and added the following point
The expert group seems to have done no work here, and the 'specification' as it stands seems to be one paragraph pointing to an external OSGi document
He goes on to state that the JCP should foster discussions and explore different avenues. In his opinion, this JSR has not done this.
Even Though the Apache Foundation
voted yes, that vote did not pass without comment. Though they pointed out that there is precedent for accepting technology from external sources (as reflected in the package structures of org.w3c etc) there was a potential for license compatibility that needed to be worked out.
we'd like a clear statement in the JCP spec license for this JSR that the necessary IP from all OSGi members is licensed on a RAND and royalty-free basis to any compatible independent implementation of this JSR. We also want to be sure that the spec license and TCK license are provided in conventional JCP manner
While it is true that Java does incorporate technologies that have specifications controlled by groups other than the JCP, this case seems a bit different in its nature. First point is that JSR 277, the Java Module System, has been created to cover many of the same issues that the OSGi addresses. However, the OSGi offers technology that is in use today while JSR 277 is still trying to resolve many basic issues that will keep it off the shelves until Java 7 at least.
This vote raises many questions. Among them are; is it proper for this JSR to just point to an external specification without any further discussion? Should the JSR be responsible to draft its own documents even if they are a carbon copy of existing specifications?