The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR #291
Dynamic Component Support for Java^TM SE
Public Review Ballot
Ballot duration: 2007-01-16 to: 2007-01-22

These are the final results of the Public Review Ballot for JSR #291. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE

Apache Software Foundation

BEA Systems

Borland Software Corporation

Fujitsu Limited

Google Inc.

Hewlett-Packard

IBM

Intel Corp.

Lea, Doug

Nortel

Oracle

Red Hat

SAP SE

SAS Institute Inc.

Suleiman, Hani

Sun Microsystems, Inc.

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2007-01-16 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-16 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-17 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-17 Nortel voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-19 Sun Microsystems, Inc. voted No with the following 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.

This vote is not intended as a negative comment on the technical merits of the OSGi work. Indeed, we are interested in cleanly accommodating current custom classloading based solutions such as OSGi in JSR 277.

However, our understanding is that, in producing this public review draft, the expert group's role has been to gather some yet not all of the requirements it meets, and that the design work and decision making took place exclusively outside the expert group and instead within the OSGi working group. 

We believe this approach for developing technology is inconsistent with the goals of the JCP to create expert groups empowered to evolve technologies, with the freedom to make design choices and technical decisions based on the needs of the Java Community.
------------------------------------------------------------------------------
On 2007-01-21 Suleiman, Hani voted No with the following comment:
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. While the specification is technically sound, I do not believe a JSR should exist merely to rubber stamp an external effort, and I fail to see the benefit to the Java community at large by assigning JSR numbers to external specifications. 

As Sun stated, the role of a expert group is to define a specification through discussion and through exploring any number of avenues, something which seems to have been lacking in this case.
------------------------------------------------------------------------------
On 2007-01-21 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-22 SAS Institute Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-22 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-22 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-01-22 Apache Software Foundation voted Yes with the following comment:
Apache votes "yes" for this stage of the process.  While we do understand the concerns of our fellow EC members regarding the JCPs 'embrace' of external specifications, we'd like to point out that there have been no challenges to the value of OSGi technology to the Java ecosystem, and there is precedent for this, as seen in Sun's inclusion external APIs such as org.w3c, org.xml.sax, and the org.omg package namespace for CORBA in Java SE.

That said, we ask that some concerns identified by the Apache community be resolved for the next stage.  If we are to validate externally-created technologies as part of the JCP ecosystem, we should ensure that those technologies conform to the JCP's IP grant and licensing structure.

We found that the spec licensing is confusing and unclear, and would like this JSR to conform to the conventions of outbound IP of the JCP.  For example, 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 - that there are no other direct licensors involved in spec and TCK licensing except the spec lead.

We suggest that you help set a precedent for open and transparent IP licensing by submitting a TCK license for public examination with the final materials that will be offered to any implementor.  You are of course able to offer any other license they choose as an alternative.

As we noted in the review ballot, we encourage you to choose an open source implementation as the RI, and deliver the TCK as open source software.

Finally, we'd like to thank the spec lead for assisting us in our discussions of this JSR.

------------------------------------------------------------------------------
On 2007-01-22 Fujitsu Limited voted Abstain with no comment.
------------------------------------------------------------------------------