These are the final results of the JSR Review Ballot for JSR #291. The Executive Committee for SE/EE has approved this ballot.
JSR291
StageJSR Review Ballot
Ballot durationFeb 28, 2006 to Mar 13, 2006
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.
Vote Log

SE/EE

On 2006-03-01 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-01 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-01 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-01 SAS Institute Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-08 Red Hat voted No with the following comment:
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.
------------------------------------------------------------------------------
On 2006-03-10 Apache Software Foundation voted Yes with the following comment:
As we are a supporter of this JSR, and a proposed member of the Expert Group, we would like to see this JSR begin.  Apache has an OSGi implementation project (http://incubator.apache.org/felix/), and therefore has an interest in how the community standardizes this technology in the Java ecosystem.

That said, we do have concerns.  We recognize that the objections of other EC members about "rubberstamping" should not be dismissed.  However, we believe that this is a judgment that can only be made later, and we welcome the opportunity to bridge two technical communities and try to remove the obvious tension between JSR-277 and OSGi.

We emphasize our interest in seeing collaborative  community engagement in the expert group, and expect that as with any other JSR, the proposed timeline will shift to accommodate the needs of EG as it does it's work.

Finally, we congratulate the spec lead on opening the expert group mail list to read-only access to any interested party, and expect that there will be no requirements for such access other than an expression of interest.  Further, in the interest of widespread adoption, we again urge the spec lead to create the RI and TCK as open source software, either through a new effort, or via one of the existing open source communities currently engaged in OSGi implementation.
------------------------------------------------------------------------------
On 2006-03-10 Oracle voted Yes with the following comment:
Oracle supports a JCP-sanctioned solution for OSGI bundling and believes JSR291 will accomplish that without undue confusion as has been cited by other members of the community.  While a Java-based OSGI solution is available through OSGI, it is Oracle's view that formalizing the JCP RI and TCK will be helpful to the Java community.  At the same time, we strongly support the work of JSR277 in addressing the next generation module specification for the platform.  We are grateful to the 277 expert group for also recognizing the need to accommodate custom class loader based solutions such as OSGI, and we feel that the formation of JSR291 will help clarify the role of OSGI modules within the broader scope of JSR277 platform specification.

------------------------------------------------------------------------------
On 2006-03-12 Nortel voted Yes with the following comment:
Nortel recognizes the importance of the work being done under the OSGi and supports the JSR291. 

We do have concerns regarding "fast-tracking" this JSR.As the member of the expert group and as a supporter, we look forward to working wiht the Spec Lead in ensuring proper due diligence is taken while working on this important JSR.


------------------------------------------------------------------------------
On 2006-03-12 Sun Microsystems, Inc. voted No with the following comment:
Sun remains unclear on the intended purpose of this JSR.

The OSGi specification already exists.  As we understand it, this
JSR does not plan to modify the specification.

JSR-277 is defining the next generation module specification for the
Java platform.  As has been noted by others, JSR-277 is intended to
cleanly accommodate current custom class loader based solutions such
as OSGi.

This vote is not intended as a negative comment on the OSGi work.
Rather, it is unclear why the community needs a JSR that merely 
duplicates the existing OSGi work. 


------------------------------------------------------------------------------
On 2006-03-13 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-13 Suleiman, Hani voted No with the following comment:
As stated in other responses, I have a number of issues with this JSR. The first of which is the 'rubberstamping' aspect, where the expert group is not allowed to modify the OSGi specification or enhance it for the needs of the greater Java community, within the JSR. The proposal seems to aim solely to have a JSR number attached to an external specification.

While further modifications to this JSR are possible in future revisions, the existence of this JSR would impose too many restrictions on these future amendment/alignment revisions.

Secondly, the timing for this JSR also places an undue burden on JSR-277. There is significant overlap between the two specifications, and the community at large would be ill-served if both sides were not prepared to offer some compromises, and attempt to minimise the overlap and ensure compatibility. JSR-291 unfortunately, due to its timeline, would force JSR-277 to take it into consideration, without reciprocating.

My vote is also not intended as a negative comment on the OSGi specs, which I believe to be technically sound and useful for many Java developers and industries, and would be happy to support a JSR based on this specification, provided it allows for a real Expert Group and can be developed, evolved, and matured within the JCP.
------------------------------------------------------------------------------
On 2006-03-13 Intel Corp. voted Yes with the following comment:
(note added after 12 EC members had voted - order in this list doesn't change when comments are added later).  We hope the JCP can continue to work with other organizations and communities in flexible ways.  e.g. W3C creates Java DOM API's and JCP decides whether or not to copy those into a JCP spec.  Or some framework (and spec) develops in open source and JCP decides whether to adopt the spec as an optional JCP spec.  In either case, development of the "spec" may continue in the other organization that initiated it (e.g. W3C) and JCP can decide whether or not it is useful to incorporate that work into an optional JCP spec.  There is no automatic rubber stamp - there is the usual process for whether to approve a spec in the JCP.  Would JCP want to exclude all possibly collaborations of that type that would result in a JCP spec?  In working with some other organization (like the hypothetical open source org that develops a framework that becomes popular) both sides always have to agree for it to wind up in a JCP spec.  In the end, the JCP benefits by the work done elsewhere and the community benefits through the added compatibility JCP provides through TCKs.
------------------------------------------------------------------------------
On 2006-03-13 Google Inc. voted No with the following comment:
Google is concerned about the relationship between JSR-277 and JSR-291.  JSR-277 defines the core platform's approach to modularity, an area that is crucial to the continuing success of the Java platform.  We are confident of JSR-277's success, but worried about the possible effects of further constraints.  We are sympathetic to JCP standardization of OSGi standards, but we believe that this task is best undertaken after the underlying foundations have been established by JSR-277.

------------------------------------------------------------------------------
On 2006-03-13 Lea, Doug voted Abstain with the following comment:
I still don't understand some of the issues here
well enough to make a voting decision. Even though
I have reservations about some of those issues I
think I do understand, out of fairness, I'm 
abstaining.
------------------------------------------------------------------------------
On 2006-03-13 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-03-13 Borland Software Corporation voted Yes with the following comment:
Borland recognizes the importance and current levels of interest and adoption of the OSGi spec by the Java Community at large. And hence the cautious "yes" vote.

However we have concerns as to what this JSR will provide over and above the OSGi if any. Moreover, we are also concerned about the overlap and relationship between JSR-277 and JSR-291. In a broader sense, we would like to see at the minimum strong interoperability between OSGi and JSR-277 and hence JSR-291.

 
------------------------------------------------------------------------------