The version information has been incorporated into the jar’s manifest and is accessible through the java.lang.Package API. getImplementationVersion() is probably what you want. See the demos.misc.VersionInfo demo for an example and the source for the JOGLAppletLauncher in com.sun.opengl.util for a concrete place where a use of the Version class was replaced with Package.getImplementationVersion().
All: the Proposed Final Draft of JSR-231 (Java Bindings for OpenGL) has just been posted:
http://jcp.org/en/jsr/detail?id=231
Please provide any feedback you have. We currently don’t have any plans to modify the APIs before the final draft, so please give us prompt feedback if there is something you think should be changed.
We are aiming to have the specification finalized by JavaOne this year, or mid-May.
JSR-231 beta 4 has been released on April 20, 2006. This release is intended to provide robustness and scalability improvements, but does not change the public API.
The following improvements have been made:
[] The locking protocol used by the on-screen GLContext implementations on all platforms has changed. The new protocol locks the drawing surface using the JAWT for only the minimal period of time necessary rather than during the entire duration between the makeCurrent() and release() calls. This primarily enables simultaneous rendering to multiple displays on multi-head X11 setups. Note that on some graphics drivers (ATI’s proprietary drivers, in particular) this optimization does not work, so for complete correctness it is still typically required to call release() periodically rather than simply makeCurrent() once and leaving the context current. This is only an issue if applications are manipulating the OpenGL context directly rather than using the GLEventListener paradigm. If necessary, the old locking behavior can be restored by specifying -Djogl.GLContext.noopt on the command line.
[] A bug fix to the X11ExternalGLContext used by the Java2D/JOGL bridge as well as by the SWT snippets which use JOGL.
[] Bug fixes and improvements to the com.sun.opengl.util and com.sun.opengl.util.texture classes.
[] Added support to the Java2D/JOGL bridge for Java2D’s EXT_framebuffer_object (FBO) mode. This may become the default mode of the Java2D/OpenGL pipeline in later Mustang builds, and can be tested with current Mustang builds by specifying -Dsun.java2d.opengl=true -Dsun.java2d.opengl.fbobject=true on the command line. Using FBOs for Java2D’s OpenGL support seems to eliminate the slowness seen on certain NVidia cards with Romain Guy’s Twinkle demo, for example.
[] Improvements to JOGL’s support of DRI-based accelerated drivers on X11 platforms.
[] A workaround for an apparent pixel format selection bug in Intel’s OpenGL drivers on Windows for 82855 and similar chips.
[] Fixed issue with multisampling in on-screen contexts on Mac OS X 10.4.x.
[] A patch from user cylab on these forums to generate javadoc links to the on-line blue book. Currently only the OpenGL 1.0 APIs are covered. Help is needed from the community to improve this support; please see this thread.
[] The native library jar files have been renamed to be more precise about the OS and CPU combination they work on, in preparation for 64-bit builds and builds on more platforms.
[] Universal binaries for Mac OS X for this release are finally available both for download as well as via Java Web Start and the JOGLAppletLauncher. They will be added to the nightly builds soon.
There are also some known issues:
[] We attempted to introduce a “GL worker thread” separate from the AWT Event Dispatch Thread (EDT) upon which all OpenGL context manipulation would be done, to maintain the default single-threaded model while decoupling from the EDT. Unfortunately for various reasons this did not work; on X11 platforms there is a potential deadlock, on Mac OS X the JAWT is unstable when used from a non-EDT thread, and on Windows platforms stability issues are introduced with applets. For the time being and for the initial reference implementation of the JSR we are planning to leave JOGL’s internal threading model as it currently stands.
[] There appear to be stability issues (intermittent crashes) with JOGL-based applets on X11 platforms (Linux, Solaris/x86) when entering and leaving the page with the applet at least with NVidia’s proprietary drivers. It is not clear whether these issues are new in beta 4 or are preexisting problems. We currently can not recommend applet-based deployment as a good solution for JOGL users and instead continue to recommend using Java Web Start.
Please try this release and post any feedback, in particular regarding its quality. Stability is our top priority, especially between now and the release of the 1.0 version of the JSR-231 reference implementation.
JSR-231 beta 5 has been released on June 8, 2006. This release improves robustness; there are no public API changes.
The following improvements have been made:
[] In JSR-231 beta 4 an optimization to the locking protocol for on-screen GLContext implementations was added, in particular to support simultaneous multi-screen rendering on X11 platforms. Unfortunately it appears that there are correctness problems with this optimization using both NVidia’s and ATI’s drivers, so it has been disabled by default in beta 5. The implication of this change is that you should not leave a GLContext permanently current on a thread, but rather should make it current and release it every frame so that on all platforms the AWT has a chance to dispatch its events. (This was basically how things worked in all releases before beta 4.) The optimization may be re-enabled by specifying -Djogl.GLContext.optimize on the command line. This is documented in the JOGL User’s Guide.
[] A couple of fixes to the Java2D/JOGL bridge, some of which were regressions due to the new support for the Java2D/OpenGL pipeline’s FBO mode in JSR-231 beta 4.
[] Bug fixes in the TextureIO package principally related to compressed textures and mipmaps, discovered by Tom Gaskins.
[] Added Xinerama awareness to solve multi-screen problems on X11 platforms on request of JB West.
[] A fix to allow external GLContexts to work with other GLContext implementations in the JOGL package after semantic changes in JSR-231 beta 4; discovered by user Tomas.
[] A new particle system demo contributed by Ben Chappell.
[] Miscellaneous bug fixes for stereo support, GLU image scaling and other areas. Thanks to users eteq, invictus and others.
[] Linux/AMD64 and Solaris/SPARCv9 native libraries are now available.
This is the last planned beta before the 1.0.0 release of the JSR-231 reference implementation. Please download and try it with your applications and report any stability problems or other bugs as soon as possible. Thanks for all of your support on this long road towards standardization.
Ken,
I have a project I am working on that uses JInternalFrames to manage several transparent JPanels over a fullscreen GLJPanel. I have no problems with the z-ordering after setting the GLJPanel opaque to false, but the performance is at a slug’s pace (about 5 fps).
To try and rule out some causes, I switched to a GLCanvas and was able to achieve my 60 fps, but of course due to the fact that it is a heavyweight component, it draws over everything.
I have ran your JRefract interoperability demo and see no difference in performance with or without the iteroperability enabled. I’ve been pulling out hair over this issue, any help would be greatly appreciated.
The same results are consistent with our entire development team. We are all developing on WIndowsXP SP2 using Netbeans 5.0. We have linked in the latest JOGL builds and are using Mustang b87.
Also: I have tried -Dsun.java2d.opengl=true
When’s 1.0.0 going to be finished? At JavaOne, the ETA for the reference implementation being released was early August, but we’re still on Beta 5.
Does anyone know? We need to make release plans, and it would add confidence to know that the 1.0.0 was going to be out of beta in time.
Thanks,
Harold Shinsato
Inxight Software, Inc.The release of 1.0.0 is imminent, probably within the next week or two. All of the materials have been submitted to the Program Management Office of the JCP and we are just waiting to hear back from them.
The final release of JSR-231 1.0.0 has been posted today, September 14, 2006!
The binaries and source code for the reference implementation of the specification are available in the Documents and Files section of the JOGL home page. The on-line JOGL demos have been updated to use the 1.0.0 release of the code. An extension JNLP file which will permanently point to the 1.0.0 release is now available at
http://download.java.net/media/jogl/builds/archive/jsr-231-1.0.0/jogl.jnlp
The “current” extension JNLP file listed in the JOGL User’s Guide is still available and is the best way to ensure your Java Web Started application is always using the most recent release.
We will continue to develop JOGL; expect a follow-on 1.0.1 release shortly (containing no API changes) which will incorporate bug fixes made since the final approval ballot was submitted.
I would like to thank you all; as members of the JOGL community your feedback on the APIs and implementation has driven the development of the project for the past three years. I look forward to continuing to work with you to evolve the project.
Congratulations! And thanks for all the hard work!
Congratulations on the final release.
What does this final label mean in practice? Does this mean the API is frozen? If so, how will support for future OpenGL extensions/versions be added?
Thanks!
API changes are done under a Maintenance Update of the JSR which is a much lighter-weight process not going through an expert group. We will probably start this process for the OpenGL 2.1 headers shortly. The nightly builds of JOGL can continue to evolve very quickly and are considered the “unofficial” builds of the RI. The version strings in these builds will be e.g. “1.0.1-pre”.
It does mean that we won’t be making any incompatible API changes going forward. If we decide to rethink something like the GLCapabilitiesChooser mechanism we will preserve the existing one and add the new API alongside it.
good work Ken!
and thanks for all your work and support here in the forums!
Felicitation ! Good work!
Is the version 1.0.0 signed ? I have a security exception in my applet !
Mathlamenace
I believe it should be correctly signed although there’s always the chance we made a mistake. Could you post a stack trace either here or maybe on a new thread?