Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 239: JavaTM Binding for the OpenGL® ES API

NOTICE: Please be aware the CDC 1.0 specification initially related to this JSR has been replace (superseded) with the newer CDC 1.1 specification. CDC 1.0 will no longer be supported after 18-Aug-2009. This JSR and other optional technologies based on the CDC 1.0 standards are fully compatible with the CDC 1.1 standards. All development and certification efforts should be updated to use the current, supported technology.

Updates to the Original JSR

The following has been updated from the original proposal.


Maintenance Lead: Roger Riggs

E-Mail Address: roger.riggs

Telephone Number: +1 781 442 0539

Fax Number: -

2006.06.20: The Spec Lead and Expert Group changed the JSR's name from "JavaTM Bindings for OpenGL ES" to "JavaTM Binding for the OpenGL® ES API"

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: sun Microsystems, Inc

Name of Contact Person: Daniel Petersen

E-Mail Address:

Telephone Number: +1 408 276 3296

Fax Number: +1 408 276 5060

Specification Lead: Daniel Petersen

E-Mail Address:

Telephone Number: +1 408 276 3296

Fax Number: +1 408 276 5060

Initial Expert Group Membership:


Supporting this JSR:


Section 2: Request

2.1 Please describe the proposed Specification:

This specification, an optional package, will describe the Java bindings to the native 3D graphics library, OpenGL ES.

OpenGL ES is largely a subset of OpenGL 1.3 and much of the work derived from JSR 231, Java Bindings to OpenGL (bases on OpenGL version 1.5) will be used in this JSR. The addition of a few OpenGL ES extensions not found in OpenGL 1.3 (or 1.5) will prevent this from being a strict subset of JSR 231.

OpenGL ES defines two profiles: the Common profile and the Common-Lite profile.

The Common-Lite profile is a 32-bit fixed-point profile while the Common profile supports floating point. The Common profile is a superset of the Commom-Lite profile. One issue for the EG is if bindings for the Common-Lite profile are needed.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The Common-Lite profile is targeted towards CLDC 1.0 environments while the Common profile is for CLDC 1.1.

2.3 What need of the Java community will be addressed by the proposed specification?

There is a need to have access to hardware accelerated 3D graphics from a low level 3D graphics library. Mobile devices are now being manufactured with hardware accelerated 3D chips. OpenGL ES is rapidly becoming the de facto standard for a platform independent, low level 3D API in the mobile market. Creating Java bindings to this library will meet the needs of the J2ME platform for 3D graphics capabilities.

2.4 Why isn't this need met by existing specifications?

There is an existing 3D API for J2ME devices, JSR 184. It provides effectively the same functionality as this JSR will. However, it is object-oriented and thus the interface to the underlying functionality is completely different from OpenGL. This JSR will cater especially to the needs of those developers who are already familiar with OpenGL, and furthermore do not require any of the high level functionality provided by JSR 184. Further, with the abundance of OpenGL applications on the market, having an API based on the OpenGL specification will ease the efforts of porting these applications to the J2ME platform. Providing Java bindings to OpenGL ES will ease the effort of moving applications from the ME space to the SE space and vice versa.

2.5 Please give a short description of the underlying technology or technologies:

OpenGL ES version 1.0, bindings for the J2ME platform.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

An OpenGL ES library must be present on the platform.

2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

First Draft: May 2004
Public Review: August 2004
Final Draft: November 2004

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered stand-alone.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Sun will make the TCK and RI available for license separately:

* TCK:
- Available free of charge to qualified not-for-profits organizations and individuals
- Licensees will be offered a flat fee, with an annual maintenance fee. At the discretion of the licensee, we will offer a per unit royalty option, with an annual maintenance fee.

* RI:
- Per unit royalty fee, with an annual maintenance fee.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

OpenGL ES documentation is available from:

3.2 Explanation of how these items might be used as a starting point for the work.

The core OpenGL ES calls will just be declared as native methods within a base OpenGL ES class. Obtaining access to device specific resources will be done via an opaque handle to make the API profile agnostic.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

Transparency plan:

a) The specification lead will maintain an interest alias for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues facing the group.

b) The specification lead will on a quarterly basis provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter.