These are the final results of the JSR Review Ballot for JSR #232. The Executive Committee for ME has approved this ballot.
JSR232
StageJSR Review Ballot
Ballot durationOct 7, 2003 to Oct 20, 2003
Votes

ME

BEA Systems
IBM
Insignia Solutions
Matsushita Electric Industrial Co., Ltd.
Motorola
Nokia Corporation
PalmSource, Inc.
Philips Electronics UK Ltd
Research In Motion, LTD (RIM)
Siemens AG
Sony Ericsson Mobile Communications AB
Sony International (Europe) GmbH
Sun Microsystems, Inc.
Symbian Ltd
Texas Instruments Inc.
Vote Log

ME

On 2003-10-08 Motorola voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-10-09 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-10-10 Insignia Solutions voted Yes with the following comment:
We believe that this represents a valuable framework for dynamic capabilities of Java devices, a solution we have long advocated. The challenge will be coordinating the current OMA DM work (which Insignia is deeply involved in) as well as OSGI specifications. It would be ideal to target CLDC platforms as well but the OSGI overhead would make that very difficult. I would suggest reviewing the inclusion of MIDlet suite support in the JSR for the sake of clarity and focus since that is not a class of apps that are applicable to CDC devices.
------------------------------------------------------------------------------
On 2003-10-10 PalmSource, Inc. voted Yes with the following comment:
1. Interaction with MIDP 2.0. The JSR authors specifically target this JSR for CDC but state that they will "describe how MIDP 2.0 MIDlet suites will be managed". This implies that a byproduct of this JSR is to decribe how CDC/Foundation and MIDP will coexist on the same device. This is a very important component of this JSR (IMHO).
 
2. Mandatory security model will be based on J2SE. This model is currently incompatible with the MIDP2.0 security model. How is this going to be managed? Will the CDC Management solution provide a sandbox for MIDP2 to play in (transparently from the enclosing management framework)?  These clarifications need to be made. 

------------------------------------------------------------------------------
On 2003-10-12 Philips Electronics UK Ltd voted Yes with the following comment:
Philips agrees with the comments from PalmSource that running MIDP MIDLets on CDC/Foundation (including security) needs to be addressed. I'm not totally sure this EG is the right place to do this.
Some aspects of this were discussed a lot in the JSR-68 EG and were one of the subjects on which input was requested during community review. See the last paragraph of section 4.2 (beginning "Editors Note & Request for Comment:").
------------------------------------------------------------------------------
On 2003-10-13 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-10-13 BEA Systems voted Yes with the following comment:
BEA is concerned about J2SE security in this context--there are some careful compromises in JSR 115 (Java Authorization Contract for Containers) to extend J2SE security for enterprise systems -- that might become an issue for this Expert Group.
------------------------------------------------------------------------------
On 2003-10-14 Texas Instruments Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-10-16 Research In Motion, LTD (RIM) voted Yes with the following comment:
The inclusion of MIDlets and MIDP 2.0 security in this JSR seems problematic and may enlarge the scope of the JSR too much.



------------------------------------------------------------------------------
On 2003-10-20 Matsushita Electric Industrial Co., Ltd. voted Yes with the following comment:
There are clearly important aspects of OSGi that should be handled in the JCP. Some issues that the EG should address are:
1. How will JCP and OSGi work together?   Are there licensing issues involved?  Where will actual technical work be done?  In OSGi? Or in the JSR EG?
2. This JSR should ensure that fragmentation does not occur for device management.  Any solution adopted for CDC should align with a solution for CLDC.  In a similar vein, if there is functionality  required by this JSR that is represented by another existing JSR, then this existing JSR should be adopted by JSR 232.
------------------------------------------------------------------------------
On 2003-10-20 Symbian Ltd voted Yes with the following comment:
This JSR addresses some very significant use cases. These use cases are relevant both to CLDC and CDC devices. 
OSGi represents some good technology, however the EG must ensure that it is the appropriate solution for the mobile space. Simpler solutions could well be possible, so it is important that the EG is driven by the use case requirements. 
------------------------------------------------------------------------------
On 2003-10-20 Sony Ericsson Mobile Communications AB voted Abstain with no comment.
------------------------------------------------------------------------------
On 2003-10-21 Sun Microsystems, Inc. voted Yes with the following comment:
Sun sees a general community need to address remote management and monitoring of Java applications and shared application-level Java
components in the device space targeted by CDC.

We're supportive of this JSR's aim to use the work of both the OSGi for the client framework and OMA DM for the protocols as starting points for
the expert group. We hope a side effect of the working model will be to further understand how to work within the JCP with the OMA.

However, we have concerns about the ambitious scope of this JSR, seeing it aim to provide technology to address use cases beyond those we see in the CDC device market (as described above) and more akin to those of the
traditional OSGi market. We are committed to ensuring a compatible market of devices which support portable applications that interoperate with underlying platform implementations in a consistent way. We believe this JSR should not overlap the scope of JSR 68 and its expert group discussions by attempting to address the requirements on CDC for providing an environment for MIDlet execution. We think the spec leads will need to liaise with the expert groups JSRs 216 through 219.

We also request a redrafted version of this JSR text after the ballot to address these and other EC members' concerns.
------------------------------------------------------------------------------
On 2003-10-21 Siemens AG voted Yes with the following comment:
In general the use cases for this JSR are targeting CDC and CLDC. It should be possible to adopt this JSR also to the CLDC space. 

1. The JSR does specify the framework to be an optional package, building block, profile, i.e. no mapping to JSR 68. Just mentioning a "framework" is not sufficient.

2. There is no statement about which type of APIs this JSR is going to specify. But there is a reference to the e.g. OMA DM which is not explained, i.e. what OMA DM would be used for. All possible implementations' interpretations are left open. E.g. will this JSR also define an API to access the OMA DM SyncML Toolkit ?

3. JSR-217 (PBP) and JSR-129 (PBP) already include the API for the application life cycle management. An explanation why a new API is needed is necessary.

4. The security issue as mentioned by the other EC members.

5. We are concerned that this JSR might mandate the usage of the OSGI framework for all CDC-based devices, which will limit the vendor's implementation alternatives of such a framework.

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