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 #288
Adaptive Java^TM ME System API
JSR Review Ballot
Ballot duration: 2006-01-03 to: 2006-01-17
These are the final results of the JSR Review Ballot for JSR #288. The Executive Committee for ME has not 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 2006-01-11 Sun Microsystems, Inc. voted No with the following comment:
Sun's vote is based on the technical merits of the JSR. Sun believes that this JSR has the following issues:

   1. Sun is not sure what problem this JSR is trying to solve. The JSR text states that this JSR will "define a mechanism" which seems to imply an implementation architecture, not a programming interface which is typically what is defined in the JCP.
   2. Many aspects of this JSR, such as the dictionary, the resource interface, the configuration API and the event mechanisms appear to conflict with ongoing work in existing Java ME JSRs (such as JSR-232, JSR-246, and JSR-278).
   3. Sun also has concerns about the ability to fully conformance test the application environment permutations possible with this JSR. It would appear from the text that the adaptive capability of a JSR-288 implementation would allow application environments to be defined after manufacture. This would make difficult the effective conformance testing of all the possible permutations of the platform, possibly allowing some instances to be non-conformant.
   4. The JSR text states that recommended practices regarding security and deterministic behavior of adaptive Java ME environments will be included in the specification. Sun believes that such a definition of predictable execution environments is already well defined in platform JSRs such as JTWI (JSR-185) and the ongoing Mobile Service Architecture work (JSR-248 and JSR-249), and that some of the concepts in JSR-288 may potentially confuse developers looking for a predictable application environment.

Sun continues to believe that developers require predictable platforms and that adaptability at this level should not be exposed to developers. We fail to see the need for this JSR in the Java Community and believe it will have a negative effect on developer expectations for Java ME.
------------------------------------------------------------------------------
On 2006-01-13 Motorola voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-01-13 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-01-14 Ericsson AB voted No with the following comment:
Ericsson votes no to this proposal since we do not see the need for standardizing much of the proposed functionality in JCP.
------------------------------------------------------------------------------
On 2006-01-15 NTT DoCoMo, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-01-15 Intel Corp. voted Yes with the following comment:
Intel has a number of reservations about this JSR, but believes that on balance it would be valuable to have the Spec Lead form an EG to elaborate and make concrete the ideas expressed in the JSR.  The resulting spec must clearly articulate how implementations of JSR 288 may complement and add value above and beyond implementations of JSR 232.   Also, the spec should avoid specifying interfaces or interactions that in the structure of typical Java ME products would be purely internal to a product; instead the spec should focus on interfaces and interactions between pieces that might be developed by different vendors.


------------------------------------------------------------------------------
On 2006-01-16 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-01-16 Nokia Corporation voted Abstain with the following comment:
We have based our vote on technical understanding of this proposal.
We have struggled to understand the proposal, but based on JSR text, found it difficult to grasp how this total system works, and our discussions with the spec lead did not completely help either. We feel that the way the suggested proposal is intended to work should be understandable based on the JSR proposal, and should not need interpretations from other parties than the spec lead. E.g perhaps a more clear explanation of the used terms and how the different concepts work/what happens in the lifecycle of the Java environment, from R&D, manufacturing to the run time deployment of applications, might have helped.

We agree that some of the problems about the platform  extendability etc. do  exist, but are concerned that for this kind of system to work in a predictable way, much more deeper specifications would be needed and only recommendations might not be enough.

It is not clear to us what is the ultimate value proposition, and for whom.
This JSR is about specifying implementation specific issues, or as described, internal system developer interfaces, but is not targeting to create any replaceable components of the Java platform.  
Further we would have wished the JSR text to address the relation of this JSR to other JSRs, e.g. JSR-246, JSR-232. It seems that this JSR is overlapping with JSR-232 in many respects (extendability, service registry, package admin, different security model)

We do appreciate that some of the problems described about the platform extendability are valid problems. But we unfortunately are not able to take a clear position at this point for a proposal about which we were not able to understand the solution mechanism nor the real value of it. 
------------------------------------------------------------------------------
On 2006-01-16 Samsung Electronics Corporation voted Abstain with no comment.
------------------------------------------------------------------------------
On 2006-01-16 Research In Motion, LTD (RIM) voted No with the following comment:
RIM has voted based on technical review of the JSR proposal as presented.  We believe that the description of the new JSR is too vague for us to understand and comment on technical feasibility, or appropriateness as a JSR. It seems the vaguely-defined targeted device is too powerful for the CLDC environment that lacks classloaders.

------------------------------------------------------------------------------
On 2006-01-16 Philips Electronics UK Ltd voted No with the following comment:
This JSR seems to be trying to standardise a lot of implementation specific details. It is very unclear to us whether there is any value to the community in standardising these.
------------------------------------------------------------------------------
On 2006-01-16 Orange France SA voted No with the following comment:
Orange's vote is based on the technical understanding of the proposal. Orange believes that this proposal has several issues:

1/ We had very time to understand the proposal. Problem targeted is not well defined, related technologies and standards are not mentioned and overall architecture remains unclear.

2/ Security issues associated with component management are not mentioned in the proposal. 

3/ Specification leader suggests that issues associated with component and integration tests have straightforward solutions, Orange does not share this analysis and is very concerned by the potential impact of test issues on Java ME fragmentation.
------------------------------------------------------------------------------
On 2006-01-17 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-01-17 Sony Ericsson Mobile Communications AB voted No with the following comment:
Sony Ericsson understands the problems this JSR are trying to solve and think that solutions to those problems are valuable. 

Sony Ericsson also like to spur new innovation.

But, we have a hard time understanding why this shall be done as a JSR. The only reason to do this job as a JSR would be to create an industry wide solution to those problems and then we would have assumed that other technology providers in this area would be supporting this JSR or be targeted to be in the expert group.

We also agree with Sun, Intel and Nokia that the relation to other efforts in this space are not clarified in the JSR text.

Therefore we have decided to vote "no" to this JSR Review Ballot.


------------------------------------------------------------------------------
On 2006-01-17 Symbian Ltd voted Abstain with the following comment:
Symbian agrees with the other comments expressed here. The proposal is too vague and it is not clear why this should be a JSR.
------------------------------------------------------------------------------
On 2006-01-17 Vodafone Group Services Limited voted No with the following comment:
Vodafone believes that the proposal is vague.
It doesn't seem to create an API which is mainly what the JCP addresses.
We see not clarified overlappings with at least 232 and 246.
There are issues as well related to security and predictability in the platform behaviour.




------------------------------------------------------------------------------