These are the final results of the JSR Review Ballot for JSR #178. The Executive Committee for ME has not approved this ballot.
JSR178
StageJSR Review Ballot
Ballot durationMar 26, 2002 to Apr 8, 2002
Votes

ME

BEA Systems
Cisco Systems
Ericsson Inc.
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 International (Europe) GmbH
Sun Microsystems, Inc.
Texas Instruments Inc.
Zucotto Wireless
Vote Log

ME

On 2002-04-08 IBM voted No with the following comment:
There are too many questions left open on the this JSR proposal relative to MIDP-NG, JSR 134 and the option of a smaller_than_MIDP profile that supports games. We would like to see progress in this area and the JSR resubmiited.
------------------------------------------------------------------------------
On 2002-04-08 Zucotto Wireless voted No with the following comment:
Zucotto agrees that there currently exists a “hole” in the Java Gaming API capabilities as defined in MIDP 1.0 and MIDP 2.0 and promotes the idea of a Java Gaming API targeted at the new CLDC/MIDP-based devices coming to market in the very near (in standards time anyway) future. We are very concerned that without a JSR to extend those capabilities defined in MIDP 2.0, device OEMs, game/graphics engine companies, game developers and wireless operators will be forced to create proprietary interfaces and erase some of  the de-fragmentation gained with MIDP 2.0.  We’re at a critical juncture in the wireless Java device industry and we must ensure the application developers and end users are well served.  

However there are a number of issues with the current submission that have been discussed during this voting session.  We have also discussed these and other issues directly with the specification lead and along with his public responses it appears that he is aligned with the cautions expressed  by Zucotto and others. Unfortunately the provisions attached to a “yes” vote are not easily enforced until the next EC vote on the JSR at Community Review -- too far into the JSR process. 

Zucotto has decided to vote No on the current proposal, but we strongly encourage the submitter to modify and resubmit the JSR, taking into account the EC recommendations and with the specific changes noted in a separate email to the ME EC and spec lead.
------------------------------------------------------------------------------
On 2002-04-08 BEA Systems voted No with the following comment:
Based on ongoing discussion, and potential fragementation (and relationship with MIDP), we believe the JSR should be revised from its current form.
------------------------------------------------------------------------------
On 2002-04-08 Philips Electronics UK Ltd voted No with the following comment:
I think the JSR needs to be revised based on the constructive discussion we've had since it was proposed. Approving the current text without taking into account this discussion seems wrong to me. The issues which need addressing include;
- is it a J2ME profile or not
- what's the relationship with MIDP
- is it constrained to be a superset of the games features in MIDP-NG
- a strong commitment for active technical co-ordination with JSR-134.
------------------------------------------------------------------------------
On 2002-04-08 Insignia Solutions voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-08 Sun Microsystems, Inc. voted No with the following comment:
The Java community has made a substantial investment in MIDP 2.0,
standardizing APIs there or in associated optional packages
(e.g. JSR-135) for popular extensions to MIDP 1.0.  The result
should be reduced fragmentation while retaining an appropriate
footprint.  

Sun is committed to the success of MIDP in the wireless space.  We
don't want to see new profiles or optional packages for wireless
devices that are not aligned with MIDP 2.0 or (theoretically) that
make a clear case for non-alignment.  On the face of it, JSR-178
appears likely to divide the momentum of MIDP and to increase
fragmentation and confusion in a deeper way than a vendor-specific API.
We also share concerns that the proposed functionality doesn't match
the footprint budget, and would like to see more evidence of alignment
with JSR-134.

Since its submission there has been productive discussion around how
JSR-178 might be modified to align better with MIDP, but we don't have
a concrete proposal for today's voting.  Sun would be more inclined
to vote for a proposal that cleanly builds on top of MIDP 2.0.
------------------------------------------------------------------------------
On 2002-04-08 PalmSource, Inc. voted No with the following comment:
As the JSR is written, PalmSource votes "no" for JSR 178 because of concerns over ambiguity and fragmentation implied in the JSR's current text.  PalmSource is not against the concept or need for specific game APIs, but we feel that the target of these APIs is not defined very well in the current text of the JSR.
For example:

- The "Profile" word: we believe your intent of profile is a "minimum set of APIs", but it's still too confusing in the J2ME world in which profiles mean and imply more than that.
- Target of CLDC devices?  That gives the impression that the API set only requires CLDC and is a complete "Profile", therefore in competition with PDAP and MIDP.  However, the target packag of javax.microedition.lcdui.game implies a required dependency on MIDP.
- The statement is confusing: "the target group of MIDP (mid-end/high-end phones) and the Game user target group (Low end phones).  In the future, MIDP will be available on the complete range of mobile phone ...".   MIDP is intended for all phones and introducing another profile (as implied by this statement) in the same space produces fragmentation.

There is a need for game APIs and PalmSource would support one, but the charter for those APIs needs to be well defined before proceeding.  We also suggest the following options for the API:

TARGET:
- If the target is dedicated handheld games devices (e.g. GameBoy type devices), then the API can exist on its own on top of CLDC and be a "Game Device Profile".
- If the target is mobile phones of any kind, the API should be a package capable of running on MIDP x.x.
- If the target is PDAs, the API should be a package capable of running on PDAP x.x.
- If the target is all of the above, then the API can be its own profile on game devices (CLDC only), and an optional package on MIDP and PDAP.
------------------------------------------------------------------------------
On 2002-04-08 Ericsson Inc. voted Abstain with the following comment:
Ericsson would prefer to see separation of the graphical and gaming components of any Gaming Profile/API.
------------------------------------------------------------------------------
On 2002-04-08 Motorola voted No with the following comment:
Thomas, Thank you for continued amplifications concerning the content of JSR-178.

We feel that the proposed content of this JSR significantly overlaps not only the content of JSR-118, but also the intended devices and usage. This is creating two different gaming APIs for MID profile compliant devices. The resultant confusion and fracture of the market place is the main concern. We believe that it will cause more fragmentation in the market space, when we are just getting a handle on reducing that fragmentation. We must maintain a consistent message on features and API sets to the development community. JSR-118 already serves the gaming areas and any changes to the API set should be worked through JSR-118.  We are also concerned that the features identified for the JSR will significantly exceed the target size for MIDP devices. 

We most vote no on this JSR to prevent competing APIs that would run on the same devices.
------------------------------------------------------------------------------
On 2002-04-08 Nokia Corporation voted No with the following comment:
Most of the reasons why we are not able to support this JSR has been in the e-mails exchanged during the last few days.
As a summary:

A large number of companies (around 60) in MIDP 2.0 expert group, discussed this issue and agreed to a plan to use the game functionality which is part of MIDP 2.0 to satisfy game development need. 
MIDP 2.0 will allow game development, but it will also be good for more general purpose. 
On top of this suitable optional APIs can be used to complement MIDP. 
 
We see that this API will increase the fragmentation of the APIs in the wireless terminals. Adding WGP would mean that some devices run games on top of it and some on MIDP 2.0 based configurations. This will increase fragmentation, not decrease.
 
The functionality proposed  is extensive and creates a danger of being larger than MIDP. 

Therefore some of the functionality in this large API that you target would in our mind be better to be implemented in a more general way so that it could be utilized in combination with MIDP.

Unlike stated in the JSR - MIDP is for low end cell phones too, not only mid/high. 

It is in this current early state of the Java enabled wireless services/applications market very important to keep the number of APIs as low as possible and therefore overlapping APIs for the same configuration (CLDC) should not be created
 
MIDP 2.0 on its part will help in defragmenting the market and manufacturers have the possibility to gradually decrease the number of proprietary APIs in the devices.
------------------------------------------------------------------------------
On 2002-04-08 Siemens AG voted No with the following comment:
Siemens shares the discussed concerns about the overlapping functionality between MIDP 2.0 and the WGP. These issues have to be resolved before a resubmission.
------------------------------------------------------------------------------
On 2002-04-08 Sony International (Europe) GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-05 Texas Instruments Inc. voted Yes with the following comment:
This vote is based on the assumption and condition that the JSR submitter MUST: 1) change the name and description from Profile to API and include the game API from JSR-118 (MIDP 2.0) as a building block per JSR-68 (J2ME Platform Specification); and 2) NOT duplicate any current or planned time-based media functionality covered by JSR-135 (Mobile Media API).
------------------------------------------------------------------------------
On 2002-04-04 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-04-03 Research In Motion, LTD (RIM) voted Yes with the following comment:
A focused game API building block designed for and by game industry players is a useful JSR.  It allows vendors to decide on their market and support targeted JSRs for their customers on their own schedule.

In retrospect, incorporating game support into MIDP NG may have been an architectural misstep but time-to-market constraints needed to be addressed.  In lieu of this, JSR 178 will need to be strictly compatible with MIDP NG and JSR 135 in order to promote J2ME source/binary compatibility.  Our YES vote should not be viewed as a vote for fragmentation rather it should be viewed as consolidating present and future Java gaming APIs into one JSR.
------------------------------------------------------------------------------
On 2002-03-30 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------