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

JSR143

StageJSR Review Ballot

Ballot durationJul 24, 2001 to Aug 6, 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-08-06 Apache Software Foundation voted No with the following comment:
We share the concerns expressed by Sun, IBM, and others, and are further concerned that the proposed timeline (one month to community review, two more to public, and three more to final) indicates a misunderstanding about the scope of the proposed JSR.  If the scope is in fact smaller, another JSR can be submitted.
------------------------------------------------------------------------------
On 2001-08-06 Lea, Doug voted Yes with the following comment:
I think this small, ambitious group ought to
be given a chance to succeed.
------------------------------------------------------------------------------
On 2001-08-06 Oracle voted No with the following comment:
Oracle votes NO on JRS 143 because we believe it is too broad.  We are concerned that it does not have the support of a significant constituency - a necessary prerequisite for success in such an ambitious undertaking.
------------------------------------------------------------------------------
On 2001-08-06 BEA Systems voted No with the following comment:
BEA concurs with the objections raised by Sun, IBM, IONA, WebGain and Borland that the scope of the subject JSR is too broad and that it needs more narrowly focussed.
------------------------------------------------------------------------------
On 2001-08-06 Progress Software voted No with the following comment:
While we consider this a very important area, IONA concurs with several of our colleagues that the JSR as proposed is overambitious.  We encourage the submitter to refocus the JSR along the lines suggested by IBM.
------------------------------------------------------------------------------
On 2001-08-06 WebGain voted No with the following comment:
WebGain votes NO because this JSR needs to be more focused on solving 
specific problems and may be less ambitious. There is definitely a clear need for
Desktop APIs but the JCP effort driving these APIs needs to be better scoped and precisely defined. Therefore, we vote NO.
------------------------------------------------------------------------------
On 2001-08-06 Compaq Computer Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-06 Borland Software Corporation voted No with the following comment:
Borland, like IBM and Sun feels the broad definitions and goals of this JSR, along with the wide range of platforms potentially affected, supports a specification that would be extremely difficult to define and implement.  For this reason Borland votes "No" on JSR 143
------------------------------------------------------------------------------
On 2001-08-06 IBM voted No with the following comment:
IBM and others in the Java Community Process have a history of building desktop applications and Desktops (Sun with Hot Java Views, IBM with the eSuite Desktop, etc...). After carefully reviewing the JSR 143 proposed specification, it is clear that that the JSR is extremely broad ranging from GUI to Security, Task/Thread management to remote update and PDA through desktop environments.    From our past experience in building desktops, it is clear that there are some core facilities that are in-common to all Desktops however it is not clear how this JSR will address all of the issues ranging from security, task/thread management, support for JNI, the user-interface design and implementation and performance to name a few areas of concern.   

Java has a rich set of APIs to define the core part of a desktop.   We recommend that either this JSR be totally rewritten further defining JavaDesk to its key component areas and how they will build into a desktop or broken up into a few JSRs that deal with the creation of the cross-platform desktop, security concerns that need to be addressed in a desktop, etc..

So, due to the very broad nature of this JSR and the lack of other information, IBM votes NO on JSR-143.
------------------------------------------------------------------------------
On 2001-08-02 Sun Microsystems, Inc. voted No with the following comment:
Sun is concerned that this JSR has very broad and
somewhat unclear goals.  It is also unclear how this JSR
relates to the many other existing Java desktop APIs.

It is possible that there may be component ideas here
that might be better pursued through separate, much more
narrowly scoped JSRs.

Desktop APIs are undoubtedly important to the future 
of the Java Platform.  We have already a very large and
rich set of desktop APIs in the shape of AWT, Swing, the
JavaBeans Activation Framework, and many others.  It may
be that we need to supplement these APIs in some areas.
However, given the impact on developers and on Java
platform ports, we need to proceed carefully and make
sure we are adding focused APIs of high value.
------------------------------------------------------------------------------