ZipException when loading native jars

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

Sven Gothel
Administrator
On 12/05/2012 08:45 PM, ryanmohr [via jogamp] wrote:

>     Sven Gothel wrote
>     .. plus my other reply regarding the proprietary status of that method.
>     I would not dare to include a blob in my project, depending on some weirdo
>     deployment and maybe even market scheme :)
>
> Exactly! The only reason we're willing to go to the work of writing a custom
> deployment process is to remove or internalize as many variables as possible.
>
> We need to be able to guarantee that the application we send to our customers
> just works (to the point that we'll soon be giving customers the option to
> have the JRE embedded, removing one more variable that's given our customers
> problems in the past).
>
> Sven -- I'm giving your suggestions a go right now.  Will let you know if I
> make any progress.  Appreciate the guidance!
You are welcome, ofc.

Pls simply share the onejar demo project (via git/github, as you wish)
and we can make an assessment whether it's a bug of GlueGen.
However, I am sure we can fix the issue.

When you create that project, it might be nice to maybe simply create
it as a jogl-demos sub-project (own folder), w/ our jogamp license,
so we can share your experience ..

~Sven



signature.asc (909 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
Project is up at https://github.com/saltybits/jogamp-onejar

Feel free to fork it and move it wherever you want.

Here's what I get when I run it:

java -jar release/release.jar

Catched ZipException: error in opening zip file, while TempJarCache.bootstrapNativeLib() of jar:file:/release/release.jar!/lib/gluegen-rt-natives-macosx-universal.jar!/ (file:/release/release.jar!/lib/ + gluegen-rt-natives-macosx-universal.jar)
java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1758)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1045)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:442)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:59)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:90)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:328)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:390)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:251)
        at com.jogamp.common.os.Platform.access$000(Platform.java:57)
        at com.jogamp.common.os.Platform$1.run(Platform.java:186)
        at com.jogamp.common.os.Platform$1.run(Platform.java:183)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:183)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:246)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:196)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:186)
        at Driver.main(Driver.java:18)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.simontuffs.onejar.Boot.run(Boot.java:342)
        at com.simontuffs.onejar.Boot.main(Boot.java:168)
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
Sven -- were you able to verify that the jar is unable to load the libraries?


On Wed, Dec 5, 2012 at 10:55 AM, ryanmohr [via jogamp] <[hidden email]> wrote:
Project is up at https://github.com/saltybits/jogamp-onejar

Feel free to fork it and move it wherever you want.

Here's what I get when I run it:

java -jar release/release.jar

Catched ZipException: error in opening zip file, while TempJarCache.bootstrapNativeLib() of jar:file:/release/release.jar!/lib/gluegen-rt-natives-macosx-universal.jar!/ (file:/release/release.jar!/lib/ + gluegen-rt-natives-macosx-universal.jar)
java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1758)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1045)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:442)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:59)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:90)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:328)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:390)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:251)
        at com.jogamp.common.os.Platform.access$000(Platform.java:57)
        at com.jogamp.common.os.Platform$1.run(Platform.java:186)
        at com.jogamp.common.os.Platform$1.run(Platform.java:183)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:183)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:246)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:196)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:186)
        at Driver.main(Driver.java:18)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.simontuffs.onejar.Boot.run(Boot.java:342)
        at com.simontuffs.onejar.Boot.main(Boot.java:168)



If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4027424.html
To unsubscribe from ZipException when loading native jars, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

Sven Gothel
Administrator
On 12/06/2012 08:45 PM, ryanmohr [via jogamp] wrote:
> Sven -- were you able to verify that the jar is unable to load the libraries?
>

Sorry, I had no time for this task yet - but will, Monday the latest.

Finally doing video rendering of our Siggraph 2012 happening and then weekend :)

Will notify you when I tested your project.

~Sven



signature.asc (909 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
Sounds good Sven.  Enjoy your weekend!


On Thu, Dec 6, 2012 at 1:14 PM, Sven Gothel [via jogamp] <[hidden email]> wrote:
On 12/06/2012 08:45 PM, ryanmohr [via jogamp] wrote:
> Sven -- were you able to verify that the jar is unable to load the libraries?
>

Sorry, I had no time for this task yet - but will, Monday the latest.

Finally doing video rendering of our Siggraph 2012 happening and then weekend :)

Will notify you when I tested your project.

~Sven



signature.asc (909 bytes) Download Attachment



If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4027432.html
To unsubscribe from ZipException when loading native jars, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

gouessej
Administrator
Does the single fat JAR approach work fine now with JOGL? It might be interesting even with Java Web Start and trusted certificates because the OCSP server can be slow and using multiple JARs means that you will have multiple OCSP requests.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
It ended up being a one or two line change to the source to be able to load the libraries as needed on our own so we just went that route.


On Thu, Feb 21, 2013 at 2:25 AM, gouessej [via jogamp] <[hidden email]> wrote:
Does the single fat JAR approach work fine now with JOGL? It might be interesting even with Java Web Start and trusted certificates because the OCSP server can be slow and using multiple JARs means that you will have multiple OCSP requests.


If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4028311.html
To unsubscribe from ZipException when loading native jars, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

Winder
Is the change in jogamp or your onejar project?  I'm having the same issue, so thanks for already doning the heavy lifting!


Catched FileNotFoundException: \UniversalGcodeSender-all64.jar (The system cannot find the file specified), while  TempJarCache.bootstrapNativeLib() of jar:file:/UniversalGcodeSender-all64.jar!/lib/gluegen-rt-natives-windows-amd64.jar!/ (file:/UniversalGcodeSender-all64.jar!/lib/ + gluegen-rt-natives-windows-amd64.jar)
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:442)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:59)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:90)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:328)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:390)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:251)
        at com.jogamp.common.os.Platform.access$000(Platform.java:57)
        at com.jogamp.common.os.Platform$1.run(Platform.java:186)
        at com.jogamp.common.os.Platform$1.run(Platform.java:183)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:183)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:246)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:196)
        at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:186)
        at com.willwinder.universalgcodesender.visualizer.VisualizerCanvas.<init>(VisualizerCanvas.java:99)
        ...

ryanmohr wrote
It ended up being a one or two line change to the source to be able to load
the libraries as needed on our own so we just went that route.


On Thu, Feb 21, 2013 at 2:25 AM, gouessej [via jogamp] <
[hidden email]> wrote:

> Does the single fat JAR approach work fine now with JOGL? It might be
> interesting even with Java Web Start and trusted certificates because the
> OCSP server can be slow and using multiple JARs means that you will have
> multiple OCSP requests.
> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website<http://tuer.sourceforge.net>| Follow
> me on Identi.ca <http://identi.ca/gouessej>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4028311.html
>  To unsubscribe from ZipException when loading native jars, click here<http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4027387&code=cnlhbi5tb2hyQGdtYWlsLmNvbXw0MDI3Mzg3fC0xMDUwMzE2MDI3>
> .
> NAML<http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

gouessej
Administrator
Winder, maybe we can find a more viable solution on the long term if you have a similar need. The JARs containing the native libraries might be modified in order to be easier to merge into a single one and GlueGen will have to be modified to load these libraries from such a fat JAR. I succeed in merging JARs with Ant, look at the task "zipgroupfileset".
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
In jogamp.  I just added a flag that prevented jogamp from loading the libraries on its own.  When our application boots up it just copies everything into place and loads them on our own.
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

Winder
In reply to this post by gouessej
I'm using the RXTX serial library which has its own native libraries, their wiki recommended using onejar. It was natural that I ran into this problem later when adding an OpenGL window to the project.

Are you willing to share your bundled fat JAR?


gouessej wrote
Winder, maybe we can find a more viable solution on the long term if you have a similar need. The JARs containing the native libraries might be modified in order to be easier to merge into a single one and GlueGen will have to be modified to load these libraries from such a fat JAR. I succeed in merging JARs with Ant, look at the task "zipgroupfileset".
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

gouessej
Administrator
I have failed to make it work reliably but I can write a request for enhancement to prepare some modifications to ease the creation of a fat JAR containing both JOGL & GlueGen classes and native libraries. Currently, you can already use Ant tasks "zip", "fileset", "zipfileset" and "zipgroupfileset" to create a fat JAR but you have to disable the automatic extraction and loading of native libraries in GlueGen and then your JAR will have to extract the native libraries somewhere at runtime because it is impossible to directly load a native library inside a JAR, there is a closed bug report about that. Then, you will have to load them by yourself by using System.load().
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
Yeah, that's exactly the approach we ended up taking.
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

gouessej
Administrator
It would be fine to ease this approach that way:
- the developer shouldn't have to load the libraries by himself, because it can become very tricky in managed environments, especially with Netbeans RCP, when you have one class loader per module and you can't load the same native library twice in a single VM. The order in which libraries are loaded may change a bit in the future...
- the libraries should be extracted into the same directory than those we already use in JogAmp. Why reinventing the wheel?

The remaining problem is about version conflicts. What happens when an end user runs two applications using different versions of JogAmp APIs?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: ZipException when loading native jars

ryanmohr
In our case we already have a designated support folder on the user's computer where we store license information and our application log.  It was a natural fit to just throw a lib directory in there and keep everything in one place.

All we did was write a simple initializer that identifies the OS, copies the proper libraries into place, and then load them before bootstrapping the rest of our application.  If it helps I'd be happy to open source the Platform library I wrote to handle the runtime identification.

Only major downside to this approach is the bloat, since the libraries for all OS's are included in every release.  For us that's an easy tradeoff to keep the deployment as simple as possible and be able to rely on a single runnable jar for windows (as exe wrapped through innosetup), mac (as app bundled), and linux.
12