Problem: Automated Native Library Loading of packed jars in JRE 7u10

The automated Native Library Loading feature of jogl is an excellent method for me to provide solid applet support on all platforms and browsers. The served jars are packed with Pack200 (producing pack.gz). Up till java 7u9, this mechanism worked excellent.

With java 7u10, packing of the native jars (gluegen-rt-natives-* and jogl-all-natives-*) stops the loading of the applet. Only when serving the native jars unpacked, the applet again starts successfully. The exception that I get when serving the native jars packed, can be found below. Occurs both on machine with Windows 7 (FF, Chrome and IE9) and on machine with OSX 10.8 (Safari 6).

Post partially to share knowledge on the issue. I'm also curious what the underlying cause is. Looking forward to your thoughts.

------------
network: Cache entry not found [url: http://[replaced]/jogl/gluegen-rt-natives-windows-i586.jar, version: null]
network: Connecting http://[replaced]/jogl/gluegen-rt-natives-windows-i586.jar.pack.gz with proxy=DIRECT
network: Connecting http://[replaced]/ with proxy=DIRECT
network: CleanupThread used 2 us
network: Downloading resource: http://[replaced]/jogl/gluegen-rt-natives-windows-i586.jar.pack.gz
        Content-Length: 7.690
        Content-Encoding: pack200-gzip
java.io.IOException: Invalid jar file
        at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)
        at com.sun.deploy.cache.Cache$4.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
        at com.sun.deploy.cache.DeployFileOutputStream.close(Unknown Source)
        at java.io.FilterOutputStream.close(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.close(Unknown Source)
        at java.io.BufferedInputStream.close(Unknown Source)
        at sun.plugin.PluginURLJarFileCallBack.downloadJAR(Unknown Source)
        at sun.plugin.PluginURLJarFileCallBack.access$000(Unknown Source)
        at sun.plugin.PluginURLJarFileCallBack$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
        at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
        at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
        at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
        at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
        at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
        at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
        at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
        at com.jogamp.common.util.JarUtil.getJarFile(JarUtil.java:332)
        at com.jogamp.common.util.cache.TempJarCache.bootstrapNativeLib(TempJarCache.java:367)
        at com.jogamp.common.os.Platform$2.run(Platform.java:234)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:225)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:171)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:90)
        at [replaced].renderengine.OpenGLUtility.checkOpenGLVersion(OpenGLUtility.java:78)
        at [replaced].applet.Applet$OpenGLVersionChecker.doInBackground(Applet.java:805)
        at [replaced].applet.Applet$OpenGLVersionChecker.doInBackground(Applet.java:799)
        at javax.swing.SwingWorker$1.call(Unknown Source)
        at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at javax.swing.SwingWorker.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
network: CleanupThread used 2 us

Hi

I think the answer is here:
http://stackoverflow.com/questions/9623837/java-web-start-broken-since-jdk-1-7

Edit.: I'm not sure SSL will solve your problem. Do you reproduce this bug with Java Web Start?

Hi,

Thanks for the feedback. Security could indeed be an issue, it would seem though that the indicated points in the post are covered or not applicable:
- I'm using the old APPLET tag and use jogl's "Automated native library loading" to load platform dependent native libraries.
- The applet is signed by an official certificate authorities
- The applet runs on a server with https enabled

All packed jars that are directly specified in the applet tag are correctly loaded. The problem occurs once the native packed jars are loaded via the automated native library loading.

Maybe it has something to do with the bug about OSCP I reported some weeks ago.

There are several problems, just look at the very end of these release notes:
http://www.oracle.com/technetwork/java/javase/7u9-relnotes-1863279.html

There is a regression in the parsing of several JVM arguments. When I succeed in working around this one, I will try to reproduce your bug. Applets don't work on my machine.

Edit.: Removing java-vm-args="-XX:MaxDirectMemorySize=128M" fixes my problem but I don't reproduce yours with Java Web Start. It seems to be specific to applets.

Please write a bug report (for JogAmp) about it. I can't investigate now but I have discovered a regression in Java Web Start when trying to reproduce your bug, thank you very much.

A few bits of extra information:
- The applet is starting without Web start / jnlp. It uses pure APPLET tag + Automatic native library loading.
- Problems occurs for Java 7u10. Java 7u09 works fine.

After additional testing, I'm more confused than ever about this problem.
- Three other Windows machines (Windows XP, 7 and 8) all work well with Java 7u10 + my applet.
- The problem is fixed on the Windows machine that gave the initial problem. Cleaning java cache, browser cache, certificate store and finally reinstalling Java 7u10 (with Windows reboots in between) didn't do the trick. Eventually installed Java 7u09 and de-activated Java 7u10, ran Applet with 7u09; then de-activated Java 7u09 and re-activated Java 7u10 and ran applet: success.
- Problem still occurs on one Mac OS X 10.8 machine. Reverted to Java 7u09 for now.

I'll wait with a bug report until I'll have at least one additional machine that has the same problem consistently.

Thanks so much for the input so far!

[Corrected type]

Thank you for the complementary information. The problem seems to come from Java 1.7 update 10. Please use the debug flags. I would like to know whether the JNLP parsing messes up with our properties and why the JAR is considered invalid. Maybe this problem comes from Pack200. I don't use it (in my first person shooter) and I have no such problem even with Java 1.7 update 10.

The debug flags unfortunately don't provide extra information. My guess is that the jogl (debug) code isn't accessed because the native jars are not available.

Your suggestion to consider Pack200 is a good one. I'm using an older JDK. Regrettably, after using the tools in the bin directory of java 7u10, the problem still occurs.

Indeed, stop using packing for the native jars does solve the problem. I was originally a bit worried that there might be an underlying larger problem. As long as the issue is confined to one machine, I can live with that ;).

On 12/14/2012 05:00 PM, karelknoes [via jogamp] wrote: I encountered a pack200 problem a while ago
and maybe it's related:

repo: jogamp-scripting
commit 14f5d5a1d1cbf9c8b829c11211030b8bd63fbfd6
<http://jogamp.org/git/?p=jogamp-scripting.git;a=commit;h=14f5d5a1d1cbf9c8b829c11211030b8bd63fbfd6>
+++

# see Java Bug 5078608
# http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078608
#
PACK200_OPTIONS="--segment-limit=-1"

++

Pls test.

~Sven

karelknoes wrote

stop using packing for the native jars does solve the problem.

Thank you very much for the feedback. I will have to write a troubleshooting guide about Java Web Start, there are so much things I do just to work around its bugs.

The option PACK200_OPTIONS="--segment-limit=-1" is indeed a good medicine against some oddities. Alas it's not the cure for this particular problem. Thank you for the tip.

On 12/17/2012 08:03 AM, karelknoes [via jogamp] wrote:
> The option PACK200_OPTIONS="--segment-limit=-1" is indeed a good medicine
> against some oddities. Alas it's not the cure for this particular problem.
> Thank you for the tip.

You are welcome.

I just installed 7u10 (32bit and 64bit) on a Windows7 64bit box
and our test applets work well .. i.e. using pack200.

Maybe your server settings are not correct?
Look up Apache server and Java JAR gz and pack200 files.

~Sven

It's very good to hear that the packed versions are also working for you, making it more likely my Mac is an exception in this issue.

My server settings in an interesting alternative venue I'll keep in mind. The Apache server I'm using is serving the native jogl jars correctly to all other test machines. The combination of OSX, Safari 6 and Java 7u10 might be a special case though.