JSR-231 1.1.1a has been posted today, June 18, 2009.

This is a patch release correcting a buffer overrun. Thanks to the Microsoft Vulnerability Research team for pointing out this issue.

This update is completely compatible with the previous JSR-231 1.1.1 release. An extension JNLP file which will permanently point at this release is available at


The preferred "current" extension JNLP file for the JOGL 1.x releases has changed because of the upcoming change to the JOGL 2 APIs:


The previous jsr-231-webstart-current link will live for the indefinite future, but the link above is now the preferred one.

Due to security concerns, all Java Web Start binaries for all previous releases of JOGL have been changed to point to the 1.1.1a binaries, and the webstart zip archives like jsr-231-1.1.1-webstart.zip have been removed. If you have re-hosted the signed JOGL binaries on your own web server, we recommend updating to the 1.1.1a version.

Please post if you run into any problems with this release. More to come soon regarding JOGL 2.

A while ago there was discussion within Sun about the possibility of signing third-party code that had been suitably audited. I'll ask one of the members of the Java security team to look at this thread and comment.

For what it's worth, I personally have no desire to put JOGL at an unfair advantage or LWJGL at an unfair disadvantage.

Forgot about the JNLPAppletLauncher, which has also been updated.

Updates to the GlueGen runtime 1.0b06, JOGL 1.1.1, JOAL 1.1.2 and Java 3D 1.5.2 have been pushed out revising the signing certificate used for these binaries. As an added, though arguably dubious, benefit, if you are running Java SE 6 Update 10 or later you will not even need to accept a security dialog.

Note though that due to bugs in Java Web Start which apparently still haven't been fixed you may need to clear out your Java Web Start cache. If you see UnsatisfiedLinkErrors against JOGL then try that.

Apologies for how long this took.

We're working on getting the new signing certificate. Sorry for the disturbance.

(First, I apologize for not keeping up on the forums recently...)

The jogl project has been converted from CVS to Subversion. Related projects like gluegen, jogl-demos, joal, and joal-demos were also converted. This will simplify ongoing development. Please post if you have any questions or comments about this change.

Work is actively going on in the JOGL_2_SANDBOX branch of the gluegen, jogl and jogl-demos workspaces. We still hope to have an "official" first beta build of the new JOGL 2 soon. JOGL 2 supports OpenGL ES 1.x and 2.0 and makes it straightforward to develop OpenGL code on the desktop which can (eventually) be deployed unmodified on mobile devices.

OpenGL context sharing is pretty basic functionality that should be well supported. I recall seeing a bug in this support in one vendor's Vista OpenGL drivers a couple of years ago but I'm pretty sure it's since been fixed.

FWIW, there is already a DDS reader in the JOGL TextureIO classes, although it is definitely possible that it needs improvement.

Given that the DirectDraw / Direct3D code in Java 2D is disabled, it's hard to guess how JOGL could be causing this hang. Your thread dumps all look OK so the hang is probably in the AWT toolkit thread, on which user code is not allowed to run, so maybe there is interference between the AWT native interface and the work being done on the AWT toolkit thread. If you have a test case it would be good if you could file a bug against the AWT on http://bugs.sun.com/ .

The branch name is JOGL_2_SANDBOX. The branch exists on the gluegen, jogl and jogl-demos workspaces. cvs co -r JOGL_2_SANDBOX gluegen jogl jogl-demos

The major features of JOGL 2 are elimination of AWT dependencies from the core JOGL API (although the GLCanvas and GLJPanel still exist in a sub-package) and support for multiple OpenGL profiles, like GL2 for the desktop, GLES1 for OpenGL ES 1.x and GLES2 for OpenGL ES 2.0, as well as common subsets. With the common subsets you can develop on the desktop and deploy onto mobile devices.

The work is still in early stages and some stuff is broken. We'll post more once it's in better shape for public consumption and broader feedback.

Are you specifying -Dsun.java2d.noddraw=true on the command line? This is required for correct operation of JOGL apps on Windows.

Unfortunately I can't reproduce this problem on Windows with the latest NVIDIA drivers. The problem on Mac OS X was a driver bug, but I don't know the root cause nor when the fix will become available (to the best of my knowledge the problem is still present if you are running 10.5.5 with certain graphics hardware). It's possible that there is something in JOGL's texture code or TextRenderer which is provoking this issue in particular, but in the limited time I had to diagnose the issue on OS X I wasn't able to find a bug.

I would suggest you try to ask for support and/or file a bug on NVIDIA's web site.

The way to do this with the current code would be to first load your mipmaps into an array of TextureData objects, and then allocate one TextureData with an array of Buffers, where the Buffers come from the original TextureDatas. Then create the Texture from the TextureData containing the mipmaps.

Does that solution work for you?

Agreed that there is functionality missing from the current code, but the JOGL 1.1.x branch is not being actively maintained right now, and the JOGL 2 branch (JOGL_2_SANDBOX branch in the source tree) is not ready for broad consumption yet. If you would like to submit a patch against the JOGL_2_SANDBOX branch that would be very welcome.

Spawn a new thread to call System.exit(). We've found that calling exit() from the Event Dispatch Thread doesn't work on all platforms. There are examples of this in the source code for the JOGL demos.

We're behind in more publicly discussing that, but for a few months now a version of JOGL has been under development which allows you to target desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.0. The various OpenGL versions are phrased as different interfaces, so you can target the common subset of OpenGL ES 1.x and desktop OpenGL, for example, and if you do this, you are pretty much guaranteed that your app will run unmodified on a mobile device. If you have a mobile device on which you can put native code, you can get this version of JOGL running on it.

This work has been going on in the open; you can check out the JOGL_2_SANDBOX branch of the gluegen, jogl and jogl-demos workspaces to see the work in progress.

There are some API restructurings we want to do before more broadly advertising the availability of this new version of JOGL, but if you try checking it out and building it, we would certainly appreciate any feedback.

Good news: we heard from Apple that they have tracked down and fixed the bug. However as is Apple's fashion they can not comment on when the fix will become publicly available. I told them we would appreciate it if they could fix it soon.

Thanks for the report. Sorry for not keeping up on the forums. See the comments on Issue 364 for our diagnosis and a workaround. Could you please point to the comments on the Apple Developer site regarding this problem (add the pointer to Issue 364)? Thanks.

Please try to produce a test case. We've received one other report of a similar bug, but haven't had time to look into it deeply yet.

Could you please file a bug with the Issue Tracker linked from the JOGL home page and attach your patch?You'll need to be an Observer of the project to do this properly.

What's your java.net user id?

Please use the jstack tool that ships with the JDK to capture a stack trace from the JVM when it locks up like this and post the result.

It would be great to incorporate this code into the joglutils project itself. Are you comfortable using Subversion? If so I can grant you commit access, otherwise one of us can incorporate the code for you.

You aren't getting any hardware acceleration for OpenGL pbuffers (either because your card doesn't support them or because your drivers are out of date) and the Microsoft software OpenGL 1.1 implementation doesn't support alpha blending sufficiently to make this demo work properly.

When you deploy JOGL and the GlueGen runtime jars you need to use the ones in the -webstart archives which you can find in the Downloads and Files section for the most recently available build from both projects' home pages on java.net. These are the signed jars for deployment.

This sounds like 6686520. Please retest with JDK 6 Update 10 build 27 when it becomes available, which contains this bug fix.

It's linked from the "Useful Links" section on the JOGL home page. You can scan it in and email it to me at kenneth dot russell at sun dot com.

Sorry, this is not possible. The Java 2D / JOGL bridge is predicated on the rendering work being initiated from the EDT. The GLJPanel rendering is then performed on a separate thread, called the Queue Flusher Thread, where the Java 2D OpenGL work is done. It's pretty complicated and doesn't admit the possibility of other threading models.

There are no licensing issues. Chris, have you signed the Sun Contributor Agreement?

Please file a bug with the JOGL Issue Tracker.

Going forward any utility routine like this will go into the joglutils project. It is likely that joglutils will start to incorporate some native code. Contributions of this or other functionality would be welcome.