These are the final results of the JSR Review Ballot for JSR #219. The Executive Committee for ME has not approved this ballot.
JSR219
StageJSR Review Ballot
Ballot durationApr 29, 2003 to May 12, 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.
Zucotto Wireless
Vote Log

ME

On 2003-05-12 Nokia Corporation voted No with the following comment:
We are worried about the fact that a new optional package, in this case JSR-209, is causing a need for this kind of a significant extension work for existing CDC/PP platform, being used in products and referenced from external standards. For clarity, we do not object filing new optional packages, but their uninformed impact to platform specs. Greater caution should be used in judging when to add mandatory features to existing platforms.
Furthermore when JSR-209 was filed, there was no mention about the connection to JSRs 216-219 and the need to make extensions to the configuration and profiles.
We ourselves have had difficulty in identifying  any real needs to make this kind of a major upgrade to the Personal Profile, PBP, FF and CDC.
 
We are concerned that the footprint of the CDC,PP, FF,PBP will be significantly increased implying a penalty for J2ME implementations, including those not implementing JSR-209.

We think that many of the proposed extensions should be made as separate optional packages and must not be mandatory for the basic platform.  
However, we understand that there may be a need to make small  updates to the existing platform, but the footprint increment of these must be kept to minimum. If this JSR is reconsidered then one such small update that should be included in this JSR is updating the Generic Connection Framework to include all the same interfaces as are defined in MIDP 2.0.


Nokia's vote is based on the technical merits of this JSR and not on the licensing terms.  Still, Nokia wants to express 
its support for license models that foster an open environment for and wide acceptance and adoption of Java specifications. 
Nokia believes that competition in implementation of Java technologies is best served through license models that are simple, predictable and affordable for a wide range of implementors. 

------------------------------------------------------------------------------
On 2003-05-12 Texas Instruments Inc. voted No with the following comment:
We feel that more consideration should be given to: 1) proposing these changes as an optional API; and 2) proposing these changes to other APIs or Profiles. It is not clear why Foundation Profile is the right place for the proposed changes.
------------------------------------------------------------------------------
On 2003-05-12 Research In Motion, LTD (RIM) voted Yes with the following comment:
RIM strongly encourages the spec lead to discuss memory footprint limitations with the EG given the highly dependent nature of these profiles.

------------------------------------------------------------------------------
On 2003-04-30 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-05-12 IBM voted No with the following comment:
We are concerned about the significant size increases necessary to support the updated versions of configurations and profiles in the proposed JSRs 216 - 219.  For a target device platform, with the proposed updates for CDC/Foundation/Personal Basis/Personal Profile plus JSR-209; we feel that the community would be better served by a J2SE execution environment.  Why create another platform that is approaching J2SE, but has differences.  Evolving this technology within J2SE assures platform consistency and no fragmentation.

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 2003-05-12 Insignia Solutions voted No with the following comment:
We believe that these functions would be better expressed as optional packages. In addition the size increase would priovide an additional hurdle to adoption. 

Insignia's vote is based on the technical merits of this JSR and not on the licensing terms.

However, Insignia would like to see a model that encourages broad adoption of a JSR without imposing terms that are potentially difficult to predict and afford.
------------------------------------------------------------------------------
On 2003-05-12 BEA Systems voted No with the following comment:
BEA concurs with the ballot comments from Philips, Motorola, Matsushita, Nokia, IBM, and Insignia and reservations stated by others.  We believe that the packaging issues should be reconsidered before resubmitting this JSR and the coordinated JSRs.
------------------------------------------------------------------------------
On 2003-05-12 PalmSource, Inc. voted No with the following comment:
We cannot support this JSR as written for one significant reason: the increase in size specified in this JSR is significantly greater than acceptable in the targeted spaces, making this fairly impossible to attain acceptance. 

Although we are voting against this for purely technical reasons, we believe that the licensing terms for this JSR seems somewhat odd, and will not foster acceptance. We encourage the spec lead to modify the business terms to help this JSR gain acceptance. 
------------------------------------------------------------------------------
On 2003-05-08 Philips Electronics UK Ltd voted No with the following comment:
We are voting against this JSR because we regard the increase in the minimum ROM size specified in the JSR to be very significantly greater than what is acceptable for a specification on which other
specifications depend and which is effectively mandatory for those other specifications to adopt.

We do not object in principle to the contents proposed for this JSR but believe a very small increase the mandatory ROM size is essential 
to avoid slowing down the replacement of PersonalJava in products by CDC/Foundation/PBP/PP. If the EG wants to include features which
cannot fit within such a small increase in mandatory ROM size then the EG should define optional packages for these features.

If this JSR is not approved then we strongly encourage Sun to revise it as described in the immediately previous paragraph and to present such a revised version for reconsideration ballot. We would prefer this JSR to proceed with these revisions rather than be thrown out completely.
------------------------------------------------------------------------------
On 2003-05-12 Siemens AG voted No with the following comment:
Siemens votes NO and shares the comments from Philips, Motorola, Matsushita, Nokia, IBM, and Insignia regarding the footprint and the relation to JSR 209. Footprint is a sensitive topic for J2ME devices and should not be increased in general for a platform without major needs. 

For the licensing terms the same comments as for 
the JSR 177 approval ballot applies. Siemens believes that there is a need for predictable costs.

------------------------------------------------------------------------------
On 2003-05-12 Symbian Ltd voted Yes with the following comment:
Symbian is voting in favour of this JSR, however we are also concerned to ensure that this and related JSRs are fit for purpose wrt to both functionality and footprint.
------------------------------------------------------------------------------
On 2003-05-12 Motorola voted No with the following comment:
Motorola votes "No" with the following reasons:

1) JSRs 216-219, as written, presume that JSR 209 as one of the fundamental reasons for the JSRs.  For example, JSR 216 says: "Additionally, the Advanced Graphics and UI (AGUI) Optional Package for J2ME (JSR-209) will require underlying platform support not present in version 1.0 of this Profile." Such a linkage is too tight a coupling in that most devices in this space will not want/need JSR 209.

2) The expected size increases are unacceptable. The CDC-based Java space needs to become _smaller_, not larger.

3) Finally, we do not see evidence that new APIs from J2SE 1.4 are required by devices in this space

Motorola recommends that these concerns be addressed and new JSRs be submitted at a later date.

------------------------------------------------------------------------------
On 2003-05-12 Matsushita Electric Industrial Co., Ltd. voted No with the following comment:
We strongly recommend these functionality to be provided as "optional package" instead of extension of FP. If this JSR is approved, the footprint size seems to be oversized for most of J2ME devices.
------------------------------------------------------------------------------