Posted by Larry Tesler on May 30, 2016; 9:24pm
URL: https://forum.jogamp.org/J3D-JOGL-make-a-Win64-app-freeze-for-1-minute-tp4036762.html

I maintain a huge Windows-only application that was written mostly by my predecessors using Java 6, ANT, NSIS and Eclipse 3.7 Indigo. A tested JRE is bundled with the product. It does not run in a web browser and does not communicate through the Internet.

The most recent major release of the app runs on Windows 7 and XP in 32-bit mode.

Using Eclipse 4.2.2 Juno, I added features and fixed bugs with the goal of shipping 32- and 64-bit Java 7 builds that run on Windows 7. A logical next step would be to upgrade to Java 8 and Windows 10.

The only 3D-based feature of the app used a version of Java3D that was at least 5 or 10 years old. Recently, that feature stopped working. After studying possible solutions and trying a few, I settled on J3D+JOGL, more precisely:

        J3D pre12 + JOGL 2.3.2 + Gluegen 2.3.2

For testing purposes, I created an Eclipse project to contain OpenGL's Pyramid example (built as an application) and a project to contain J3D+JOGL (to be shared between Pyramid and my app).  

Unfortunately, that attempt failed. The presence in the stack trace of names like TempFileCache suggested that a not-unexpected culprit was to blame: a corporate security policy that caused Automated Native Library Loading to freeze.

Goodbye to automation. I got the Pyramid example working perfectly in 64-bit mode by adding:

        -Djogamp.gluegen.UseTempJarCache=false

and

        -Djava.library.path=C:\Users\myname\workspace\JOGL\jogamp-all-platforms\lib\windows-amd64

to VM args and by setting the native library locations of gluegen-rt and jogl-all to

        JOGL/jogamp-all-platforms/jar/atomic.

The 3d-based feature and everything else in the application now works as it should, with one huge exception: Some thread (seemingly the interactive event loop) blocks for 60 seconds soon after launch, even when the 3D-based feature has not been invoked by the user. The app can often be shaken out of its stupor in less than a minute by using Eclipse debug mode to pause and resume the main thread.

A 60-second freeze is, well, not a feature that customers will appreciate. Because the only changes I made to my application before the freeze appeared were ones necessary to get it working with the excellent JOGAMP technologies, I would like to rule the latter out as a cause of the pause.

Is there any activity that Gluegen or some other technology performs as an application starts up (before any OpenGL method is called) that might cause a thread to wait for 60 seconds?

Does JOGL or Java3D do anything with Security Manager that might be a factor?

Is anything in my installation suspect?