Bug 537

Summary: New USE_TEMP_JAR_CACHE inhibits running directly from class files
Product: [JogAmp] Gluegen Reporter: Wade Walker <wwalker3>
Component: coreAssignee: Sven Gothel <sgothel>
Severity: normal    
Priority: ---    
Version: 2   
Hardware: pc_x86_64   
OS: all   
Type: --- SCM Refs:
791dacb29bcd6d7ed161c6bd2abf7937c7d00691 1b88a636af0c7d85ed14a2395d65f813cb14f98c 9a211fe6cfb4150d97b50325c1778b7f5d3419af
Workaround: ---

Description Wade Walker 2011-12-15 15:30:03 CET
The new USE_TEMP_JAR_CACHE flag in Platform.java causes failure if you try to run a JOGL app that depends directly on the compiled .class files (instead of on the JAR). This happens (for example) if you run a project from inside an IDE like Eclipse, and your project depends directly on the gluegen and jogl projects (instead of depending on their JAR files).

I've got a fix prepared for this that I'll submit soon, I just need to test it on other platforms.
Comment 1 Sven Gothel 2011-12-18 16:15:09 CET
Attempt to simply suppress the IllegalArgumentException in case the class is loaded from the plain
filesystem - not the JAR file.

No need to toggle USE_TEMP_JAR_CACHE flag, since the use should be transparent,
ie fallback properly using the 'old style'.

If this is not the case (now), pls let me know how to fix it.
Comment 2 Wade Walker 2011-12-30 21:56:06 CET
Reopened after verifying that this bug is still there in the latest release. Submitted pull request for my fix at https://github.com/sgothel/gluegen/pull/8.

I tested this fix on Win 7, CentOS, and OS X, and it fixes the problem on all three platforms.

The commit is at https://github.com/WadeWalker/gluegen/commit/1b88a636af0c7d85ed14a2395d65f813cb14f98c.
Comment 3 Sven Gothel 2012-01-04 08:42:13 CET
Merge pull request #8 from WadeWalker/bug_537_jar_cache_prevents_running_from_class_files

Fix JAR cache to allow running from class files.
Fixes bug 537.

Note: We may need to verify why commit 791dacb29bcd6d7ed161c6bd2abf7937c7d00691
is not sufficient.

.. since it's a crucial part of our architecture, Wade's patch pre-emptive avoids using the JAR 
cache in case it's running from a plain class file based environment.
However, the JAR Cache utilization shall fail and fall back to the traditional style, 
hence work transparent. This is obviously not the case .. so I like to know the culprit.
Comment 4 Wade Walker 2012-01-04 15:35:52 CET
I tried making it "fall through" when it tries to set up the JAR cache, but this didn't work cleanly -- that's why I turned off USE_TEMP_JAR_CACHE instead. Here's a full explanation:

The original failure happens in JarUtil.getJarSubURL() here:

if(!urlS.startsWith("jar:")) {
  throw new IllegalArgumentException("JAR URL doesn't start with 'jar:', got <"+urlS+">");

This exception is not caught in Platform.loadGlueGenRTImpl(), so it causes failure. If I catch that exception, more exceptions are thrown from GLProfile.initSingleton():

Catched: JAR URL doesn't start with 'jar:', got <file:/work/jogl2/jogl/build/jogl/classes/javax/media/opengl/GLProfile.class>
Catched: JAR URL doesn't start with 'jar:', got <file:/work/jogl2/jogl/build/nativewindow/classes/jogamp/nativewindow/NWJNILibLoader.class>
Catched: JAR URL doesn't start with 'jar:', got <file:/work/jogl2/jogl/build/nativewindow/classes/jogamp/nativewindow/NWJNILibLoader.class>

This is because Platform.loadGlueGenRTImpl() calls TempJarCache.initSingleton() before it tries to load the JAR, so later when GLProfile.initSingleton() calls TempJarCache.isInitialized(), it thinks the JAR cache is initialized when it's really not.
Comment 5 Sven Gothel 2012-01-05 08:59:04 CET
The exception messages you are referring to start w/ 'Catched',
meaning we have handled them and should not cause any harm.
Result is that no native JAR files are added to the cache.
A latter JNILibLoaderBase.loadLibrary() will not find them and just move on to the traditional

But as you pointed out, commit 791dacb29bcd6d7ed161c6bd2abf7937c7d00691
missed the catch of IllegalArgumentException in Platform.loadGlueGenRTImpl(),
hence GlueGen native library wasn't loaded - great catch.

Latest commit 9a211fe6cfb4150d97b50325c1778b7f5d3419af
cleans up the determination whether we run from a JarURL
using the same logic and reusing JarUtil, instead of testing for file protocol only.
The commit also catches IllegalArgumentException in Platform.loadGlueGenRTImpl(),
hence the fall through should work as well.

I hope it's rock solid now, please verify.