JOGL with JWrapper deployment, FileNotFoundException "gluegen-natives-macosx-universal.jar"

Hi I'm trying to deploy my application with the very promising JWrapper but I get the following, exception.

I don't understand the reference to "gluegen-natives-macosx-universal.jar" as I do not have this on my machine anywhere and still this same project works fine when launched form within Eclipse and using my old one-jar bundled stuff (which admittedly uses the individual natives).

Below also a listing of the JWrapper created deployment directory, what file am I missing?

Or could this be a access right issue as I understand the the jogl/gluegen need to extract the native files somewhere?

br Kusti


Catched FileNotFoundException: /Users/nyholku/Library/Application Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/gluegen-natives-macosx-universal.jar (No such file or directory), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/Users/nyholku/Library/Application%20Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/gluegen.jar!/com/jogamp/common/os/Platform.class, nativeJarBaseName gluegen-natives-macosx-universal.jar): [ file:/Users/nyholku/Library/Application%20Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/gluegen.jar -> file:/Users/nyholku/Library/Application%20Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/ ] + gluegen-natives-macosx-universal.jar -> slim: jar:file:/Users/nyholku/Library/Application%2520Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/gluegen-natives-macosx-universal.jar!/
java.lang.UnsatisfiedLinkError: Can't load library: /System/Library/Frameworks/gluegen-rt.Framework/gluegen-rt
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854)
        at java.lang.Runtime.load0(Runtime.java:795)
       




nyholkus-MacBook-Pro:jwrapper-build nyholku$ ls -l /Users/nyholku/Library/Application\ Support/JWrapper-EazyCNC/JWrapper-EazyCNC-00031812779-complete/
total 56400
-rw-r--r--  1 nyholku  staff      3553  6 Nov 07:21 AppleJavaExtensions.jar
-rw-r--r--  1 nyholku  staff   2704487  6 Nov 07:20 EazyCNC.jar
-rwxr-xr-x  1 nyholku  staff    715027  6 Nov 07:21 EazyCNCLinLauncher32
-rwxr-xr-x  1 nyholku  staff    797684  6 Nov 07:21 EazyCNCLinLauncher64
drwxrwxrwx  3 nyholku  staff       102  6 Nov 07:21 EazyCNCMacLauncher32.app
drwxr-xr-x  3 nyholku  staff       102  6 Nov 07:21 EazyCNCMacLauncher64.app
-rwxr-xr-x  1 nyholku  staff    479539  6 Nov 07:21 EazyCNCWinLauncher.exe
-rwxr-xr-x  1 nyholku  staff     73511  6 Nov 07:21 JWAppSpec-EazyCNC
-rwxr-xr-x  1 nyholku  staff        98  6 Nov 07:21 JWAppSpec-JWrapper_Service_Management_App
-rw-r--r--  1 nyholku  staff       965  6 Nov 07:21 JWLaunchProperties-1415251263708-41
-rwxr-xr-x  1 nyholku  staff     23711  6 Nov 07:21 JWrapper-EazyCNC-ICNS.icns
-rwxr-xr-x  1 nyholku  staff     51174  6 Nov 07:21 JWrapper-EazyCNC-UninstallerICO.icopng
-rwxr-xr-x  1 nyholku  staff     59127  6 Nov 07:21 JWrapper-EazyCNC-splash.png
-rwxr-xr-x  1 nyholku  staff        11  6 Nov 07:21 JWrapper-EazyCNC-version.txt
-rwxr-xr-x  1 nyholku  staff        11  6 Nov 07:20 JWrapper-JWrapper-version.txt
-rwxr-xr-x  1 nyholku  staff       368  6 Nov 07:21 JWrapperLaunch
-rw-r--r--  1 nyholku  staff        12  6 Nov 07:21 JWrapperUseJRE
-rwxr-xr-x  1 nyholku  staff     90112  6 Nov 07:20 SimpleService.exe
-rwxr-xr-x  1 nyholku  staff     47704  6 Nov 07:20 elev_mac
-rwxr-xr-x  1 nyholku  staff      4322  6 Nov 07:21 gluegen-rt-natives-macosx-universal.jar
-rw-r--r--  1 nyholku  staff    260540  6 Nov 07:21 gluegen-rt.jar
-rw-r--r--  1 nyholku  staff    651688  6 Nov 07:21 gluegen.jar
-rw-r--r--  1 nyholku  staff    905853  6 Nov 07:21 jna-4.0.0.jar
-rwxr-xr-x  1 nyholku  staff    429822  6 Nov 07:21 jogl-all-natives-macosx-universal.jar
-rw-r--r--  1 nyholku  staff   4344747  6 Nov 07:21 jogl-all.jar
-rw-r--r--  1 nyholku  staff         0  6 Nov 07:21 jwFirstRun
-rwxrwxrwx  1 nyholku  staff        13  6 Nov 07:21 jwLastRun
-rwxr-xr-x  1 nyholku  staff       792  6 Nov 07:20 jwrapper_license
-rw-r--r--  1 nyholku  staff    955101  6 Nov 07:21 jwrapper_utils.jar
drwxrwxrwx  5 nyholku  staff       170  6 Nov 07:20 jwrapperlib
-rwxr-xr-x  1 nyholku  staff     90112  6 Nov 07:21 jwutils_win32.dll
-rwxr-xr-x  1 nyholku  staff     98304  6 Nov 07:21 jwutils_win64.dll
-rwxr-xr-x  1 nyholku  staff      5892  6 Nov 07:21 libjwutils_linux32.so
-rwxr-xr-x  1 nyholku  staff      8019  6 Nov 07:21 libjwutils_linux64.so
-rwxr-xr-x  1 nyholku  staff     24228  6 Nov 07:21 libjwutils_macos32.jnilib
-rwxr-xr-x  1 nyholku  staff     20644  6 Nov 07:21 libjwutils_macos64.jnilib
-rwxrwxrwx  1 nyholku  staff     67376  6 Nov 07:20 lzma64
-rw-r--r--  1 nyholku  staff    191239  6 Nov 07:20 miglayout-3.7.jar
-rwxr-xr-x  1 nyholku  staff     59127  6 Nov 07:20 nativesplash.png
-rw-r--r--  1 nyholku  staff    193060  6 Nov 07:20 purejavacomm-0.0.21.jar
-rw-r--r--  1 nyholku  staff    151602  6 Nov 07:21 purejavahidapi.jar
-rw-r--r--  1 nyholku  staff  15278495  6 Nov 07:21 tools-jdk1.7.0-u60.jar

Hi

Sorry to tell you this but in my humble opinion, JWrapper isn't bad but it's not promising. As it's not open source, you don't really know that it does under the hood and if it gets discontinued, you'll be alone with this tool and unable to fix it without reverse engineering. As JWrapper is proprietary, it's a black box, I can't look at its source code and tell you "we should modify this part to make it work" if your trouble comes from it. Maintaining proprietary tools is none of our concerns (in my humble opinion). JWrapper has a limited free of charge version but it's a commercial product and I don't work for free for profitable organizations. I have to pay my bills. If the problem comes from JWrapper, its authors can contact us and we'll find a kind of agreement to make things work.

You need to provide the native libraries for GlueGen and JOGL. Use the JARs gluegen-rt-natives-macosx-universal.jar and jogl-all-natives-macosx-universal.jar (no need to set the Java library path) or the individual native libraries (+ set the Java library path).

Moreover, there are similar open source and fully free of charge solutions. PackR provides most of JWrapper features except the Java installation APIs, the build-in multi-language support, the build-in signing and the update mechanism. I use my own tool (based on PackR) and several JogAmp users gave a try to PackR. JWrapper seems to use Oracle Java and I'm not 100% sure that it respects "Oracle's redistribution terms" despite the vague claims on its website whereas PackR supports both Oracle Java and OpenJDK.

I already have a working example for OS X, jmaasing tested my zipped APP bundle several months ago. Do you want to use a solution that just works for free? The most important missing feature is the update mechanism. PackR creates a directory containing your application and the OpenJDK JRE, it can minimize the latter. Then, you just have to make a ZIP of this directory and that's all. When the end user downloads the zipped APP file, OS X automatically unzips it and recognize it as an application. PackR produces similar ZIP files for GNU Linux and Windows, my tool goes even further by creating RPMs and DEBs.

I have looked at JWrapper's documentation and I have found nothing about native libraries. In my humble opinion, if you want to make it work very simply and without exposing yourself to the limitations and bugs of this tool, make a (fully working) fat JAR and give it to JWrapper instead of using tons of separate files. It's a first step, you can make something cleaner as a second step.

Look at how we handle the JARs.

Just as a reminder, PackR is under a permissive license suitable for commercial applications too. My tool is under GPL v2 but you can use my instructions to do something similar without it. "similar" doesn't mean "exactly the same".

Edit.: Please check that you haven't used gluegen.jar instead of gluegen-rt.jar.

Edit.2: Don't include gluegen.jar:
-rw-r--r--  1 nyholku  staff    651688  6 Nov 07:21 gluegen.jar

Edit.3: purejavahidapi is a nice API. I'll implement similar features in NEWT Input API :)

Please can you confirm that removing gluegen.jar and keeping gluegen-rt.jar solve your problem?

-rw-r--r--  1 nyholku  staff    260540  6 Nov 07:21 gluegen-rt.jar
-rw-r--r--  1 nyholku  staff    651688  6 Nov 07:21 gluegen.jar

Hi (gain) gouessej!

And thanks for your considerate opinions.

I solved my immediate problem late last night. It seems that for years I've been nurtusing a bastard setup for packaging my application which caused all the problems (witness my previous mails last year relating to .jnilib / .dylib loading etc).

So I bit the bullet, started from scratch and used JOGL 2.2.4 and now everything builds nicely and cleanly using just gluegen-rt-all and jogl-all jars like this:

        <File classpath='yes' path="jogl-all.jar" >../jogamp-all-platforms-v2.2.4/jar/jogl-all.jar</File>
        <File classpath='yes' path="jogl-all-natives-macosx-universal.jar" >../jogamp-all-platforms-v2.2.4/jar/jogl-all-natives-macosx-universal.jar</File>
        <File classpath='yes' path="gluegen-rt.jar">../jogamp-all-platforms-v2.2.4/jar/gluegen-rt.jar</File>
        <File classpath='yes' path="gluegen-rt-natives-macosx-universal.jar">../jogamp-all-platforms-v2.2.4/jar/gluegen-rt-natives-macosx-universal.jar</File>

(Just saw your other response and I see this is exactly what you proposed so you are vindicated!)

As to JWrapper, I agree that it is not great that it is not Open Source, but now that I've solved the above issue it seems to work so my main risk in using it is wasted two evenings … if explodes on me I just have to just find something else and so far JWrapper has been the only solution that ticks all my boxes…until your post that is!

I did not know about 'packr', I will have a look cause obviously an open source and free (as in beer) for my free would be preferable. However from your description it looks like it misses the step that I personally want most: single executable file (.app .exe) that embeds the JRE, I do not want a directory where the JRE is side by side with the .app or .exe). But hopefully I'm wrong and 'packr' does this, I will have a look.

JWrapper seems to get everything just right, the only problem seems to be that it is not open (the requirement to show their branding is a small nuisance and from what I've dig into it seems to respect Oracle licensing).  For profitable organisations the price is a non issue. I saw one or two rough corners in the documentation but if it is not discontinued they will fix those I'm sure. Overall it was a very good experience and worked mostly out of the box and it comes with batteries included so to speak.

Re 'rpack' OpenJDK and automatic updates: IMHO OpenJDK on Mac is not yet up to par with Oracle so I won't be using that for a while, so that is a non issue for me. For my application automatic or even semiautomatic updates are *not* wanted … in fact would be nuisance and dangerous as this is a CNC machine application where you don't want anything to change under you and preferably the computer is not even networked.

Once more thanks for the help, the great work on JOGL and the great support on it AND sharing your thoughts re JWrapper / rpack, I appreciate it very much.

nyholku wrote

I did not know about 'packr', I will have a look cause obviously an open source and free (as in beer) for my free would be preferable. However from your description it looks like it misses the step that I personally want most: single executable file (.app .exe) that embeds the JRE, I do not want a directory where the JRE is side by side with the .app or .exe). But hopefully I'm wrong and 'packr' does this, I will have a look.

It create a directory {appname}.app that is seen as a single file under Mac OS X and it uses several native launchers (.exe under Windows). As you don't have to rebuild those launchers, you can use it under any OS. It can be improved.

nyholku wrote

JWrapper seems to get everything just right, the only problem seems to be that it is not open (the requirement to show their branding is a small nuisance and from what I've dig into it seems to respect Oracle licensing).

Sorry to contradict you but PackR uses OpenJDK for legal reasons, not for the love of free software and I know that if its both main contributors could use Oracle Java, they would. However, you can use Oracle Java with PackR, just set the "jdk" parameter to point out to an Oracle JDK and it will extract the JRE from it.

nyholku wrote

For profitable organisations the price is a non issue. I saw one or two rough corners in the documentation but if it is not discontinued they will fix those I'm sure. Overall it was a very good experience and worked mostly out of the box and it comes with batteries included so to speak.

My biggest concern is that I'm not paid to fix their bugs and JWrapper is a commercial product. Yes, numerous profitable organizations are often willing to pay when the price is reasonable but you don't have any access to JWrapper's source code which means that you will have almost no mean to fix it and instead of waiting for it to get broken, it might be more viable on the long term to use a viable alternative right now.

nyholku wrote

Re 'rpack' OpenJDK and automatic updates: IMHO OpenJDK on Mac is not yet up to par with Oracle so I won't be using that for a while, so that is a non issue for me.

You can already have working unofficial builds of OpenJDK for OS X usable with PackR that work very well under OS X >= 10.7.3 but you can use Oracle Java with PackR anyway.

nyholku wrote

For my application automatic or even semiautomatic updates are *not* wanted … in fact would be nuisance and dangerous as this is a CNC machine application where you don't want anything to change under you and preferably the computer is not even networked.

Then, JWrapper is less appealing in your case.

nyholku wrote

Once more thanks for the help, the great work on JOGL and the great support on it AND sharing your thoughts re JWrapper / rpack, I appreciate it very much.

You're welcome. I can help to make things work but if I suspect that the problem comes from JWrapper itself, it will be its support team's concern. If you make a fat JAR (even though it isn't very smart), it will help you to test JWrapper's competitors and it will drive you less dependent on it. There are JarMatey and One-Jar (you seem to know it) too.

Edit.: Launch4j can help to create a single executable under Windows.
Edit.: An application launched with PackR doesn't create a process called "java.exe" under Windows like JWrapper.
Edit.: My tool (!= PackR) handles the icons property too whereas you have to provide your own .icns and .ico files to PackR.