These are the final results of the JSR Review Ballot for JSR #111. The Executive Committee for SE/EE has approved this ballot.
JSR111
StageJSR Review Ballot
Ballot durationMar 20, 2001 to Apr 2, 2001
Votes

SE/EE

Accenture
Apache Software Foundation
Apple Computer, Inc.
BEA Systems
Borland Software Corporation
Caldera Systems
Cisco Systems
Compaq Computer Corporation
Fujitsu Limited
Hewlett-Packard
IBM
Lea, Doug
Oracle
Progress Software
Sun Microsystems, Inc.
WebGain
Vote Log

SE/EE

On 2001-04-02 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-04-02 Borland Software Corporation voted No with the following comment:
Borland shares the concerns expressed by Sun, BEA, Caldera and Doug Lea.
------------------------------------------------------------------------------
On 2001-04-02 WebGain voted No with the following comment:
WebGain likes the basis of this JSR, but also believes that the scope is too broad and has concerns on the impact to the development process.
------------------------------------------------------------------------------
On 2001-04-02 Sun Microsystems, Inc. voted No with the following comment:
Sun shares the concerns expressed by BEA, Caldera,
and Doug Lea.  At present the JSR seems overly
broad and vague.  It may be appropriate to define
some APIs in this space, but we would suggest that
a narrower and more focused JSR is more desirable,
and is more likely to achieve widespread adoption.
------------------------------------------------------------------------------
On 2001-04-02 Apache Software Foundation voted Yes with the following comment:
Apache believes, from a pure technological point
of view, a framework as discussed in this JSR needs more direct research (even if current
Avalon is reaching the point where it's solid enough from a design point of view) and research cannot easily be done at a JSR level.  However, we are willing to give the nod to this JSR with the following considerations:

1) This JSR should *NOT* have a tight schedule: developing a framework is something that takes time, even with lots of previous experience.

2) Apache is very happy to contribute to the global experience in this field with one or more Avalon developers.  We suggest the mailing list be run in an open manner, similar to JSR-102.

3) Apache offers to host the reference implementation, and will be glad to refactor Avalon's next generation to make it compliant with what the JSR comes out with, if the Avalon community finds it appropriate to do so.
------------------------------------------------------------------------------
On 2001-04-02 Lea, Doug voted No with the following comment:
This proposal is in too preliminary a state to approve. It whould be reworked to be more concrete and to indicate interactions with other
JSRs. Alterntively, the proposers may wish to
consider working within other existing JSRs to
achieve their goals.
------------------------------------------------------------------------------
On 2001-04-02 Fujitsu Limited voted Yes with the following comment:
We consider this JSR should describe more clearly the coverage of this JSR and the relationship with JSR96 and other JSRs.
------------------------------------------------------------------------------
On 2001-04-02 IBM voted Yes with the following comment:
IBM are voting yes, with some reservations over the scope of this proposed framework JSR. On balance, we feel that the effort has sufficient potential of value that it is worth letting an Expert Group get to grips with a more detailed work definition. If this proceeds, we recognize the risk of a no-vote at Community review if we're surprised (although similar comments could be made about other recent JSRs).
Coexistence with certain other JSRs needs addressing early by the Expert Group. Specifically:
- We assume that this JSR can coexist with JSRs for J2EE 1.x, without requiring co-requisite changes/extensions if possible,
- Co-ordination with JSR 109 (Implementing Enterprise Web Services) is vital (and has been agreed, I believe),
- Continued commitment to keeping in sync with JSR 96 (Java Daemons) is also necessary.
------------------------------------------------------------------------------
On 2001-04-02 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-30 BEA Systems voted No with the following comment:
BEA is concerned that this JSR is overly broad in scope, and not sufficiently well understood to be ready for standardization. We are also not convinced that the envisioned uniform services model for all of Java is desirable given the substantial usage differences between J2EE, SE, and ME. Finally, BEA would also like to better understand why this JSR is directly relevant to the rank and file Java developer---i.e., what are the salient APIs going to look like? (Systems programming JSRs inherently should have a more compelling case behind them than those focused at Java APIs).
------------------------------------------------------------------------------
On 2001-03-30 Caldera Systems voted No with the following comment:
Caldera views this project as overly ambitious and needs to better defined.
------------------------------------------------------------------------------
On 2001-03-30 Compaq Computer Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-23 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-23 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-03-23 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------