537 2011-12-15 15:30:03 +0100 New USE_TEMP_JAR_CACHE inhibits running directly from class files 2012-01-05 08:59:04 +0100 1 1 3 JogAmp Gluegen core 2 pc_x86_64 all RESOLVED FIXED --- normal --- 1 wwalker3 sgothel --- 791dacb29bcd6d7ed161c6bd2abf7937c7d00691 1b88a636af0c7d85ed14a2395d65f813cb14f98c 9a211fe6cfb4150d97b50325c1778b7f5d3419af --- oldest_to_newest 1280 0 wwalker3 2011-12-15 15:30:03 +0100 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. 1286 1 sgothel 2011-12-18 16:15:09 +0100 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. 1311 2 wwalker3 2011-12-30 21:56:06 +0100 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. 1315 3 sgothel 2012-01-04 08:42:13 +0100 http://jogamp.org/git/?p=gluegen.git;a=commit;h=3eb4fd96cd65e49625663fdb6421a2f1cf2204dc +++ 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. 1320 4 wwalker3 2012-01-04 15:35:52 +0100 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. 1325 5 sgothel 2012-01-05 08:59:04 +0100 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 System.loadLibrary(libraryName). 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.