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 #239
Java^TM Binding for the OpenGL^® ES API
Final Approval Ballot
Ballot duration: 2006-08-15 to: 2006-08-28

These are the final results of the Final Approval Ballot for JSR #239. The Executive Committee for ME has 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-08-16 IBM voted Yes with the following comment:
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 2006-08-16 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-21 Orange France SA voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-24 Motorola voted No with the following comment:
It is Motorola's understanding that issues still remain with the JSR 239 specification, most notably the manner with which EGL interfaces with the relevant profile's user interface and graphics APIs such as LCDUI.  While the specified API is adequate from a functional perspective, it has fundamental issues that limit the performance potential of hardware-accelerated devices.  These concerns have been raised with the specification lead and no action has been taken.

However, it is also recognized that JSR scoping rules may limit the ability of JSR 239 to fully address these issues.  Therefore, Motorola would like to see profile specific behaviors removed from this specification, thereby allowing the appropriate profile JSRs (MIDP, PBP, etc.) to define the integration of EGL with specific user interface APIs and the corresponding behaviors in a more efficient manner.

------------------------------------------------------------------------------
On 2006-08-25 Research In Motion, LTD (RIM) voted Abstain with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Vodafone Group Services Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Nokia Corporation voted Abstain with the following comment:
We also share some concerns about the integration of EGL and the graphics context APIs of the profiles.
We would like to see the issues raised within the expert group being appropriately handled
------------------------------------------------------------------------------
On 2006-08-28 Siemens AG voted Abstain with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Philips Electronics UK Ltd voted Abstain with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Samsung Electronics Corporation voted Abstain with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2006-08-28 Sony Ericsson Mobile Communications AB voted No with the following comment:
The main motivation to vote against the proposed final draft for JSR-239 is the fundamental contradiction that exists between the EGL as specified in JSR-239, and the MIDP specification. 

This contradiction is a question about the procedure in which drawing surfaces are bound and used. A procedure which differs in a fundamental way between the MIDP standard, and the proposed final draft of JSR-239.

MIDP dictates that a new paint surface is given for each frame and must not be cached, and all usage of the graphics object is restricted to the paint method. From the MIDP specification:

�Operations on this graphics object after the paint() call returns are undefined. Thus, the application must not cache this Graphics object for later use or use by another thread. It must only be used within the scope of this method.�

The EGL paradigm on the other hand, dictates that a surface is created once and then used throughout the application. This in turn implies a caching of the graphics object in the EGL surface. From the proposed final draft:

"On JME CLDC/MIDP platforms, native_window must be an instance of 
javax.microedition.lcdui.Graphics object created directly from an 
instance of GameCanvas or from the argument supplied to the 
Canvas.paint method."

"A Graphics instance obtained from the argument to Canvas.paint may be reused in subsequent paint calls targeting the same Canvas."

As a consequence of this contradiction, the JSR-239 implementation is dependent on platform specific implementation of MIDP�s canvas mechanism. I.e. the JSR-239 specification might not work on some platforms without extensive modification of the native MIDP implementation. 

To fully eliminate this contradiction calls for rather drastic measures. A solution to this problem would be either changing the canvas model of MIDP, or changing the EGL itself. As the MIDP canvas model is accepted and widely used, the latter proposal seems more feasible. 

Changing the EGL could be done in several ways. Our proposal is roughly to replace it with a model that better suits the MIDP standard. 

This new solution could inherit from JSR-184�s Graphics3D model (or the JSR-226 ditto), and might be called GraphicsGL. Used in a similar way as the Graphics3D, the GraphicsGL would better respect the limitations of the MIDP canvas model. 

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