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 #171
Java Community Process^SM (JCP) Program, version 2.5
Community Draft Ballot
Ballot duration: 2002-08-06 to: 2002-08-12

These are the final results of the Community Draft Ballot for JSR #171. The ECs have approved this ballot.

Votes

SE/EE

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

Macromedia, Inc.

Nokia Networks

Oracle

Progress Software

Sun Microsystems, Inc.

BEA Systems

Cisco Systems

Ericsson Inc.

IBM

Insignia Solutions

Matsushita Electric Industrial Co., Ltd.

Motorola

Nokia Corporation

PalmSource, Inc.

Philips Electronics UK Ltd

Research In Motion, LTD (RIM)

Siemens AG

Sony International (Europe) GmbH

Sun Microsystems, Inc.

Texas Instruments Inc.

Zucotto Wireless

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2002-08-12 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Apache Software Foundation voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Caldera Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Progress Software voted Yes with the following comment:
IONA votes 'Yes' to take this JSR to Community Review with the understanding that the specification will move forward and positively, to remove some of the concerns currently directed as the current version.
------------------------------------------------------------------------------
On 2002-08-12 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Nokia Networks voted Yes with the following comment:
Even if Nokia would like to see that a Spec that is independently implementable shall stay like that, we vote yes to make progress in having the new JSR rules in effect. Things are not perfect and we need to continue developing the JCP rules further. Sun's latest JSR 171 JCP process change is addressing the "continued availability" by trying to make the intentions of the Spec Lead visible w/r the independent implementation possibility of the Spec in the future and allowing more time for ECs to consider the decision. We strongly recommend that this information on the JSR Form is made mandatory and that forms which are missing or are not clear with this respect of this information, shall not be brought to the EC ballot at all. This check should be PMO's responsibility in the Process Document. The EC then need to be very conservative with regard to allowing Specs be subsumed by profile of platform edition.
------------------------------------------------------------------------------
On 2002-08-10 Cisco Systems voted Yes with the following comment:
Things aren't always black & white. So long as we move towards positive progress, it is OK to leave a few things out. No doubt there will be more changes in the future and in the meantime we all need to work around the limitations.
------------------------------------------------------------------------------
On 2002-08-10 Lea, Doug voted Yes with the following comment:
As everyone knows, this isn't perfect, but is worth
taking to the next phase, in part to help work out
IBM's concerns in light of other feedback we may
receive.
------------------------------------------------------------------------------
On 2002-08-08 IBM voted No with the following comment:
IBM has consistently worked within the JCP since its inception to create an open environment with a level playing field where no single vendor has the ability to exert unnecessary control over Java technologies for their own proprietary advantage.  JCP 2.5 contains a new provision that ratifies spec leads’ ability to withdraw Java technologies from stand-alone availability, making them available only as a component within a Java Platform.  

This action would prohibit licensees’ existing Java products based on those stand-alone JSRs from evolving with the best-of-breed Java technologies, and creates an environment where this ability could be used to create proprietary advantages.  Also, since creating and maintaining complete implementations of Sun’s enterprise platform specifications in the open source community is unrealistic, this new provision could effectively preclude the open source community from contributing to the evolution of key Java technologies.  

While we do not believe this ability would be used intentionally to block access to Java Technologies, IBM - along with the majority of the group given the mission to negotiate this new process document - supported alternatives that addressed the cost issue of the ongoing maintenance of stand-alone technologies while at the same time allowed the stand-alone specification to remain available.  One alternative simply allows another interested member of the Java Community to commit to the spec lead role for evolving the stand-alone spec, effectively addressing both concerns. 

As a result of the likely impact of this provision on companies that have products dependent on stand-alone Java technologies, and the impact on the open source communities’ participation in the Java community, IBM is voting no.  We hope that Sun Microsystems, as Expert Group leaders, will seriously explore the alternative approach in more depth.
------------------------------------------------------------------------------
On 2002-08-06 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------

On 2002-08-12 Ericsson Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Zucotto Wireless voted Yes with the following comment:
Zucotto's YES vote comes with the assumption that the final few detials will be addressed to resolve some of the issues expressed by the EC members. There are some specific details we'd like to see fixed/added including:

"Expert Groups that need to quickly create or update a J2ME Building Block should approach the Maintenance Lead for the J2ME Platform Edition Specification with their requests."

- who is maintenance lead for J2ME platform? It can’t be found on JCP web site (at least not easily)

1.3 JSR Approval Ballot failure

- should bar similar JSRs with duplication of functionality from being resubmitted by others during the 14 day resubmission period if the original submitter has indicated they desire a reconsideration ballot

Section 2.0

- I’d like to see EC members provided with access to JSR expert groups to monitor progress and ensure requirements placed on JSR votes are being met
- First draft is often too late to make substantive changes/comments

3.1

"The Spec Lead is responsible for ensuring that all public comments are read and considered. If those comments result in revisions to the draft, and those revisions result in major changes (in the opinion of the Expert Group), then the Specification Lead will send an updated draft (with synopsis of the changes) to the PMO who will post both items to the JCP Web Site and notify both Members and the public"
- has this ever happened? 
- Perhaps all later revisions should be posted for public review to provide a level playing field for all who are implementing the spec prior to final release


A.4 EC SELECTION PROCESS AND LENGTH OF TERM

-we'd like to see the number of elected seats be at least equal or similar to the number of ratified seats to better reflect the community and ensure participants are ready to be actively involved
- Perhaps a phased process where 1 ratified seat is converted to an elected seat per year?
------------------------------------------------------------------------------
On 2002-08-12 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Texas Instruments Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Insignia Solutions voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-12 Philips Electronics UK Ltd voted Yes with the following comment:
Philips agrees with the various other comments saying that while this isn't perfect, it is a big step forwards and should proceed..
------------------------------------------------------------------------------
On 2002-08-12 Sony International (Europe) GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-11 Nokia Corporation voted Yes with the following comment:
Even if Nokia would like to see that a Spec that is independently implementable shall stay like that, we vote yes to make progress in having the new JSR rules in effect. Things are not perfect and we need to continue developing the JCP rules further. Sun's latest JSR 171 JCP process change is addressing the "continued availability" by trying to make the intentions of the Spec Lead visible w/r the independent implementation possibility of the Spec in the future and allowing more time for ECs to consider the decision. We strongly recommend that this information on the JSR Form is made mandatory and that forms which are missing or are not clear with this respect of this information, shall not be brought to the EC ballot at all. This check should be PMO's responsibility in the Process Document. The EC then need to be very conservative with regard to allowing Specs be subsumed by profile of platform edition.
------------------------------------------------------------------------------
On 2002-08-11 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-11 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-11 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-08-09 Motorola voted Yes with the following comment:
While JSR-171 may not be perfect, it and the associated JSR-99 are significant steps forward in improving the Java community.
------------------------------------------------------------------------------
On 2002-08-08 IBM voted No with the following comment:
IBM has consistently worked within the JCP since its inception to create an open environment with a level playing field where no single vendor has the ability to exert unnecessary control over Java technologies for their own proprietary advantage.  JCP 2.5 contains a new provision that ratifies spec leads ability to withdraw Java technologies from stand-alone availability, making them available only as a component within a Java Platform.  

This action would prohibit licensees existing Java products based on those stand-alone JSRs from evolving with the best-of-breed Java technologies, and creates an environment where this ability could be used to create proprietary advantages.  Also, since creating and maintaining complete implementations of Suns enterprise platform specifications in the open source community is unrealistic, this new provision could effectively preclude the open source community from contributing to the evolution of key Java technologies.  

While we do not believe this ability would be used intentionally to block access to Java Technologies, IBM - along with the majority of the group given the mission to negotiate this new process document - supported alternatives that addressed the cost issue of the ongoing maintenance of stand-alone technologies while at the same time allowed the stand-alone specification to remain available.  One alternative simply allows another interested member of the Java Community to commit to the spec lead role for evolving the stand-alone spec, effectively addressing both concerns. 

As a result of the likely impact of this provision on companies that have products dependent on stand-alone Java technologies, and the impact on the open source communities participation in the Java community, IBM is voting no.  We hope that Sun Microsystems, as Expert Group leaders, will seriously explore the alternative approach in more depth.
------------------------------------------------------------------------------
On 2002-08-08 Matsushita Electric Industrial Co., Ltd. voted Yes with the following comment:
Matsushita approves the community review of JSR 171 especially after the significant progress that has been made in the the writing and discussions on the new JSPA. We hope that such a progress will continue to take into account issues such as the specificities of J2ME platforms and multi- platform JSRs.

 There is a following unclear point to be clarified by the public review:
 After the platform edition or profile JSR and EC approves the request for inclusion from a JSR, what actions should be done next?:

  Who should deliver the integrated RI and TCK? 
  Does the existing platform edition or profile JSR which includes a JSR, go to the maintenance steps.
------------------------------------------------------------------------------
On 2002-08-06 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------