JSR-231 (Java Bindings for OpenGL) is finally in the Early Draft Review stage! This is the first official publicly visible draft of the forthcoming JSR-231 APIs. You can download the specification here:http://jcp.org/en/jsr/detail?id=231
The spec is basically the javadoc target of the JSR-231 branch of the JOGL workspace. The only packages covered by the spec are javax.media.opengl and javax.media.opengl.glu. The others are "utility" packages not guaranteed to be shipped by any particular implementor of the JSR-231 APIs.
The specification is fairly minimal, primarily covering the cross-platform exposure of the GLContext and GLDrawable abstractions. The current JOGL callback model, which is similar to GLUT's, is also supported through the GLAutoDrawable API. All of the concrete OpenGL widgets and drawables shipped with the JSR-231 implementation (GLCanvas, GLJPanel, and GLPbuffer) implement the GLAutoDrawable interface. If desired, end users can use the GLDrawable and GLContext APIs directly to either grab the underlying OpenGL context from one of the existing widgets, or can easily create their own OpenGL widgets supporting different, non-callback rendering models like game loops.
All of the APIs have been implemented and tested on all of JOGL's supported platforms. There are some known issues on certain kinds of machines like Mac PowerBook laptops, but by and large the new code base is more robust than the current JOGL 1.1.1 release. Exciting new functionality like the Java2D/JOGL bridge, previously mentioned
on this forum, is built in to the new implementation. There are some new demos in the jogl-demos workspace which show off the new functionality and performance enhancements.
While most JOGL applications will require very few changes to work under the new APIs, some application changes will definitely be necessary, and there are many cosmetic and some semantic changes to the APIs. We will try to provide a definitive list of the differences between the current JOGL APIs and the new JSR-231 APIs soon. A few key points:
- All non-core APIs like the Animator have been moved into the com.sun.opengl.utils package. We aim to populate this package with utilities like texture loaders, screen grabbers, etc. Help from the community would be greatly appreciated.
- APIs which accept a void* argument on the C side now accept java.nio.Buffer on the Java side rather than overloadings for each primitive array type. Some APIs like glVertexPointer require that this Buffer be direct; others, like glTexImage2D, do not. If the buffer must be direct, this is specified in the API. JOGL applications which used to call these APIs by passing in primitive arrays can be converted to the new API by using <Type>Buffer.wrap(). This change was done to reduce the explosion of overloadings for various APIs.
- APIs which accept a strongly-typed C primitive pointer argument like int* are expanded to two overloadings, one taking an IntBuffer and optionally one taking an int. If the API requires a persistent pointer, only the IntBuffer variant will be generated, and the passed buffer must be direct. If not, both overloadings will be generated, and the IntBuffer may be direct or not.
- The positions of passed Buffers are now significant; the pointer passed down to C is the address of the current element in the Buffer rather than the beginning of the Buffer. This decision was informed by the LWJGL project so as to avoid needing to create slices of Buffers. Please provide feedback on this stylistic change.
- Access to the GLU library has changed. Rather than being attached to the GLDrawable, a GLU object can now be instantiated at any point in the program, and the GL object does not need to be passed to all of the methods. The GLU routines which use OpenGL require only that an OpenGL context is current at the point where they are called. The GLUT library has been refactored similarly.
- All of the OpenGL extensions which were folded into 1.1, 1.2, and 1.3 have been excluded during the glue code generation process. This eliminates some pretty useless extensions like glVertexPointerEXT and on the whole seems like the right thing to do. It does imply that these extensions will not be callable if the host's OpenGL implementation is not at least OpenGL 1.3 compliant; however, an OpenGL 1.3 implementation is not required in order to run applications using only OpenGL 1.1 or 1.2 APIs.
- Vertex Buffer Object and Pixel Buffer Object support has been changed. APIs affected by these extensions now have two overloadings generated, one for use when the extension is enabled (accepting a Java long in place of a C pointer like void*) and one for when it is disabled (accepting a Buffer in place of a C pointer). Checks are performed at run-time to ensure that arbitrary pointers can not be constructed by end users and passed in to the OpenGL implementation.
Nightly builds and new Java Web Start binaries are coming on line and should be available within a day or two. We will post updates to this forum when they are available. The JSR-231 branch of the JOGL tree will also soon be merged on to the main trunk, at which point all JOGL development going forward will be on the new APIs.
The Early Draft Review period is scheduled to last for roughly a month, followed by the public review period. Compared to the length of time the JSR has been underway, we realize that this is a relatively short period of time in which changes to the specification can be made. Please provide your feedback on the new APIs and spread the word to others that the specification is in the review phase.
We are looking forward to a speedy review process and getting the final APIs in the hands of developers and end users. Thanks in advance for your help.