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 #324
On Screen MIDlet API for Java ME
JSR Review Ballot
Ballot duration: 2008-04-01 to: 2008-04-14
These are the final results of the JSR Review Ballot for JSR #324. The Executive Committee for ME has not approved this ballot.
Votes

Dautelle, Jean-Marie
Ericsson AB
IBM
Intel Corp.
Motorola
Nokia Corporation
Orange France SA
Philips Electronics UK Ltd
Qisda Corporation
Research In Motion, LTD (RIM)
Samsung Electronics Corporation
Siemens AG
Sony Ericsson Mobile Communications AB
Sun Microsystems, Inc.
Time Warner Cable Inc.
Vodafone Group Services Limited
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

On 2008-04-03 Dautelle, Jean-Marie voted Yes with no comment.
------------------------------------------------------------------------------
On 2008-04-07 Samsung Electronics Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2008-04-08 Qisda Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2008-04-10 Nokia Corporation voted No with the following comment:
Nokia votes No because we think that JSR 271 MIDP 3 covers the area of idle screen integration in a sufficient and well designed way. This proposed new JSR seems to have a very high overlap with MIDP 3 and would likely result in this JSR creating a solution that is conflicting with the solution from MIDP 3. While this JSR describes some additional features compared to MIDP 3, we think that it would have been appropriate to bring these as requirements in the MIDP 3 EG and have the discussion first inside MIDP 3. According to our knowledge, these issues have not been raised in MIDP 3 EG at all. Our opinion of the proposed new features is that some of them would be highly problematic to implement in the proposed form while needing to ensure reliable operation of the phone and integration to all the phone functions. 
In general, we feel that the current solution in MIDP 3 is sufficient and any additional requirements would be appropriate to raise first in the MIDP 3 EG as this area clearly is already in the scope of MIDP 3.
------------------------------------------------------------------------------
On 2008-04-11 Sony Ericsson Mobile Communications AB voted No with the following comment:
Sony Ericsson votes No on this JSR for several reasons. We believe that most of the requirements for idle screen is covered by MIDP 3.0 (JSR 271). Sony Ericsson is concerned that the submitters have not taken the time or spent the effort to raise those requirements in the JSR 271 EG or consulted the JSR 271 spec lead to address them. This will result in yet more fragmentation. We recommend that submitters do that first and with the clear goal of identifying the ovelaps and gaps and have the MIDP 3.0 consider the gaps for inclussion in the MIDP 3.0 work.
------------------------------------------------------------------------------
On 2008-04-11 Orange France SA voted Abstain with the following comment:
Orange strongly believes that MIDP 3.0 existing framework should be able the ideal place to host, address and widely promote into the market place all the requirements reflected in this JSR 324 proposal. Hence, Orange recommends the introduction of idle screen feature into the midp 3 tracker (instead of the creation of a stand alone JSR addressing that particular topic).
------------------------------------------------------------------------------
On 2008-04-11 IBM voted No with the following comment:
IBM votes NO because we believe there is too much overlap between this JSR and JSR271.  The requirements listed in the request should first be presented within JSR271 (which we understand has not happened).

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2008-04-14 Sun Microsystems, Inc. voted Abstain with the following comment:
Sun Microsystems agrees that the features proposed by this JSR are useful and currently missing in MIDP3. Adding the features to MIDP 3 is a better alternative though and given the current status of MIDP3 which allows for its inclusion,we vote Abstain assuming the MIDP3 EG will put it on the agenda on its next F2F meeting.
------------------------------------------------------------------------------
On 2008-04-14 Motorola voted No with the following comment:
Motorola's position is that the scope and intent of this JSR would be best developed within JSR 271, in order to avoid further fragmentation and duplication. As spec lead of JSR 271, Motorola welcomes this discussion and development within the MIDP 3.0 EG.
------------------------------------------------------------------------------
On 2008-04-14 Ericsson AB voted No with the following comment:
We do not consider the use cases presented in the JSR proposal to be strong enough to warrant a new JSR. We would prefer to have the missing features introduced as design proposals to the JSR271/MIDP3 Expert Group for inclusion in that spec.
------------------------------------------------------------------------------
On 2008-04-14 Vodafone Group Services Limited voted No with the following comment:
Vodafone has been engaged with the spec lead in discussing the merits of an on-screen midlet API as suggested by JSR 324.
We see the benefits and further believe, that the currently proposed feature scope of JSR 324 is not fully covered by similar midlet APIs in MIDP 3.
Thus, from a use case and feature perspective we support the idea presented in JSR 324.  From a specification perspective, we eventually concluded it is feasible and better to cover the specification of such midlet by the ongoing MIDP 3 effort: similarity of functionality, forecasted wide availability of MIDP 3, less risk of fragmentation incl. reduced risk of fragmentation in MIDP implementations, coverage through one MIDP 3 TCK speak in favour of covering the proposal in MIDP 3. We anticipate the difference between the new proposal and what is specificed in MIDP 3 to be small. A separate JSR would further introduce administrative overhead and lead to additional TCK licensing costs for implementers.
Thus, we not only refer to MIDP 3, but we are supportive to start the appropriate analysis in MIDP 3.
------------------------------------------------------------------------------
On 2008-04-14 Siemens AG voted No with the following comment:
The scope of this JSR needs close relation to JSR 271. Without detailed discussions this stand alone JSR will lead to overlap or fragmentation. The spec lead should discuss the scope and goals with JSR 271.
------------------------------------------------------------------------------
On 2008-04-14 Philips Electronics UK Ltd voted No with the following comment:
Philips is unable to support this JSR for the same reasons as given by the other EC members.
------------------------------------------------------------------------------
On 2008-04-14 Research In Motion, LTD (RIM) voted No with the following comment:
RIM votes NO because we also feel the issues raised by this JSR should be addressed in MIDP proper.

------------------------------------------------------------------------------
On 2008-04-14 Intel Corp. voted Abstain with the following comment:
Intel abstains due to a lapse in our internal process.  Unfortunately this lapse was solely mine and I apologize for it.
------------------------------------------------------------------------------