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 #279
Service Connection API for Java^TM ME
JSR Review Ballot
Ballot duration: 2005-07-19 to: 2005-08-01

These are the final results of the JSR Review Ballot for JSR #279. The Executive Committee for ME has approved this ballot.

Votes

Ericsson AB

IBM

Intel Corp.

Matsushita Electric Industrial Co., Ltd.

Motorola

Nokia Corporation

NTT DoCoMo, Inc.

Orange France SA

Philips Electronics UK Ltd

Research In Motion, LTD (RIM)

Samsung Electronics Corporation

Siemens AG

Sony Ericsson Mobile Communications AB

Sun Microsystems, Inc.

Symbian Ltd

Vodafone Group Services Limited

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

On 2005-07-19 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-07-20 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-07-28 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-07-29 Siemens AG voted No with the following comment:
Siemens agrees with the need of a high level API to improve the current JSR 172 API and to be able to accommodate for Web Services based infrastructures, as for example IDWSF framework. 
However, we have to vote NO because the proposed name and text of JSR 279 defines a too broad and fuzzy scope. The broad definition is reflected in the JSR name, which claims to be "the" interface in the J2ME space to access services, and in some portions of the JSR text, e.g. in the sections 2.1,  2.6 and 2.7.  The broad scope is also in conflict with the scope of other JSRs which enable access to services, e.g. JSR 172, JSR 259 and JSR 281 and might cause confusion.
 
We would like to see the scope of this JSR consolidated and would change the Siemens vote to YES in this case.

------------------------------------------------------------------------------
On 2005-07-29 Orange France SA voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-07-29 Vodafone Group Services Limited voted Yes with the following comment:
We are in favour for this JSR but we would like to comment that the platform it should run upon is described in an unclear way saying "This JSR is defined to be compatible with CLDC/MIDP and should be easily implemented in CDC-based platforms as well". We would like to have a clearer commitment for CDC.
------------------------------------------------------------------------------
On 2005-08-01 Symbian Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Sony Ericsson Mobile Communications AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Motorola voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Philips Electronics UK Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Intel Corp. voted No with the following comment:
Intel supports the general intent of this JSR to develop an API to abstract the process of connecting to a network service.  However, the JSR (at the end of section 2.7) appears to specifically preclude the EG from specifying an interface between implementations of this JSR and implementations of specific frameworks and/or protocols.  The lack of such an interface ensures that each implementation will either be inextensible or that it will invent its own extension mechanism, thus rendering the framework or protocol implementations nonreusable.  One might note that Java�s dynamic nature actually can make such provider interfaces quite simple.  For instance, the specification of javax.microedition.io.Connector.open describes a naming convention by which Connector locates protocol-specific class implementations.  Together with a constructor calling convention, this is sufficient to allow new protocols to be supported in a standardized way. If an EG had tried to design such an interface and found insurmountable obstacles, that would be one thing, but precluding the EG from considering an architecturally desirable feature we think makes the JSR unacceptable.
We urge the Spec Leads to resubmit this JSR modified to include a commitment to a standardized modular architecture instead of a constraint that appears to preclude it.

------------------------------------------------------------------------------
On 2005-08-01 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-08-01 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------