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.
The following has been updated from the original proposal.
2006年09月14日:
Maintenance Lead: Roger Riggs
E-Mail Address: roger.riggs Telephone Number: +1 781 442 0539 Fax Number: -
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: daniel.petersen@sun.com Telephone Number: +1 408 276 3296 Fax Number: +1 408 276 5060 Specification Lead: Daniel Petersen E-Mail Address: daniel.petersen@sun.com Telephone Number: +1 408 276 3296 Fax Number: +1 408 276 5060 Initial Expert Group Membership:
Sun Supporting this JSR:
TI
Section 2: Request
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.
The Common-Lite profile is targeted towards CLDC 1.0 environments while the
Common profile is for CLDC 1.1. 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. 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. OpenGL ES version 1.0, bindings for the J2ME platform. javax.media.opengles An OpenGL ES library must be present on the platform.
No No No First Draft: May 2004 The primary means of communication will be email, with conference calls and
face-to-face meetings scheduled as needed. The RI and TCK will be delivered stand-alone. N/A
Sun will make the TCK and RI available for license separately:
* TCK:
* RI:
Section 3: Contributions
OpenGL ES documentation is available from: 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)
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.
Symbian
ATI
Nokia
2.1 Please describe the proposed Specification:
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
2.3 What need of the Java community will be addressed by the proposed specification?
2.4 Why isn't this need met by existing specifications?
2.5 Please give a short description of the underlying technology or technologies:
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?
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.
Public Review: August 2004
Final Draft: November 20042.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.
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.
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.
- 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.
- Per unit royalty fee, with an annual maintenance fee.
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.
http://www.khronos.org/ 3.2 Explanation of how these items might be used as a starting point for the work.
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.