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 #320
Services Framework
JSR Review Ballot
Ballot duration: 2007-10-30 to: 2007-11-12
These are the final results of the JSR Review Ballot for JSR #320. The Executive Committee for ME has approved this ballot.
Votes

BenQ Corporation
Dautelle, Jean-Marie
Ericsson AB
IBM
Intel Corp.
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.
Vodafone Group Services Limited
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

On 2007-11-12 Orange France SA voted Yes with the following comment:
Orange does not agree the proposed API overlaps with existing technologies. As pointed by IBM & Sun, there is no JSR in this area for CLDC; therefore it is possible; there are use cases and capable devices, therefore it is needed. Options proposed by IBM are strange, OSGi supporters have always claimed it is not possible to adapt OSGi to CLDC and the only evolution proposed for CLDC has always been CDC. If evolution of CLDC or OSGi are possible, this should be discussed in JSR 320 expert group, not objected to JSR 320 creation. 
------------------------------------------------------------------------------
On 2007-10-31 Sony Ericsson Mobile Communications AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-11-01 BenQ Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-11-12 Dautelle, Jean-Marie voted No with the following comment:
Please could you provide examples of services whose management would be facilitated by this JSR. I have difficulty assessing the usefulness of this JSR. Since this JSR is disputed for others reasons (e.g. overlapping with existing JSR) it seems preferable to go back to the drawing table and reach a consensus with IBM/RIM about the best approach here.
------------------------------------------------------------------------------
On 2007-11-06 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-11-08 Philips Electronics UK Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-11-09 Sun Microsystems, Inc. voted Yes with the following comment:
JSR 320 intended functionality as described in the JSR text, attempts to cover a remarkable narrow functionality gap. This gap is located somewhere in between already existing life cycles for different application models, existing/in work JSRs which cover service consumption and application deployment and management functionality. Therefore the API has to be carefully and strictly defined to avoid API fragmentation and overlapping.
------------------------------------------------------------------------------
On 2007-11-11 IBM voted No with the following comment:
JSR 232, which is already available, appears to provide a solution to all the requirements expressed within this JSR 320 proposal, other than running within a CLDC environment. IBM believes that it would be possible for any CLDC platform provider to integrate the framework specified within JSR 232 by either exploiting a private Class Loader API, or by exposing the standard Class Loader API in a revision of CLDC - and believes both of these to be better alternatives. To satisfy the implied resource constraints of CLDC, we further recommend that the proposer should approach the Spec Leads of JSR 232 to request a maintenance release to make some of its services optional for a CLDC environment and enable just the core framework to run on these two forms of CLDC. This recommendation would enable JSR 232 and JSR 291 to continue to maintain symmetry across Java Editions and configurations which are working together to better unify the Java community's approach.

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 2007-11-09 Motorola voted Yes with the following comment:
As proposed, JSR 320 fills a need for a low to mid tier services management architecture that not feasible in CLDC class devices without a major revision to that configuration in terms of scope and platform requirements. Such a change to CLDC would have far reaching effects on dependent Java ME profiles and optional packages, as well as MSA (JSR 248) and MSA-A (JSR 249).
------------------------------------------------------------------------------
On 2007-11-12 Intel Corp. voted No with the following comment:
The assertion that it would be useful to have a software management framework adapted to the constraints of CLDC seems reasonable.  However, as other EC members have pointed out in their comments, such functionality already exists in various forms for Java ME, so inventing something new and unrelated to the existing solutions is not a good idea.  The lack of consideration of how the proposed functionality would relate to JSR 232 seems a particularly unfortunate omission.  We believe that the community would be better served by a proposal that is clearly focused on drawing upon the existing technologies in crafting a solution for CLDC.

------------------------------------------------------------------------------
On 2007-11-12 Research In Motion, LTD (RIM) voted No with the following comment:
Even without IBM's point about possible overlap in scope with JSR 232, RIM feels that the proposed API will not provide sufficient value to offset the disruption to existing CLDC software and service architectures.
------------------------------------------------------------------------------
On 2007-11-12 Vodafone Group Services Limited voted Yes with the following comment:
Vodafone vote yes, BUT with the following major comments: Although this JSR covers a broader range of device classes it seems to duplicate a lot of functionality which are already covered by JSR 232. In order to prevent fragmentation in the market we strongly encourage the EG of this JSR to take into account what already has been achieved in JSR 232 and to keep the overlap as low as possible. A roadmap and scope clarification should be created where the relationship and the evolution of JSR 320 and JSR 232 is clearly defined. We also see the need to base this JSR on open standards like OMA SCOMO instead of introducing yet another framework based on a proprietary approach. We acknowledge that there is a bit of a gap for CLDC devices and vote YES but strongly recommend to consider the mentioned concerns.

------------------------------------------------------------------------------
On 2007-11-12 Siemens AG voted Yes with the following comment:
Siemens has concerns regarding the overlap of this JSR with existing JSRs as other EC members have already pointed out. The expert group has to clearly address this overlap in their work to find a solution witch fits in the existing JSR landscape to get approval for further steps.
------------------------------------------------------------------------------
On 2007-11-12 Nokia Corporation voted Yes with the following comment:
Nokia votes Yes. However, we note that this JSR seems to partly overlap with JSR 232, although we acknowledge the partly different scope. We encourage the EG to evaluate adopting a subset of the JSR 232 API in order to minimize fragmentation. Any possible new APIs to be defined in this JSR should concentrate on such scope that minimizes overlap with JSR 232.

------------------------------------------------------------------------------
On 2007-11-12 Samsung Electronics Corporation voted Yes with no comment.
------------------------------------------------------------------------------