Posted by ThinWhiteDuke on Nov 02, 2016; 12:20pm
URL: https://forum.jogamp.org/Java-3D-initialization-is-super-slow-tp4037070p4037373.html

gouessej wrote

You're welcome. I understand that this bug is annoying but keep in mind that the automated native deployment doesn't work on restricted machines on which it isn't allowed to uncompress files in the usual locations. In other words, this mechanism is very handy but you can totally stop using it with a very few efforts in your deployment methods. Personally, I bundle my own game with an OpenJDK JRE, I totally control how it gets installed, everything is currently automated with Ant. If you use a single "fat" JAR, this workaround prevents you from going on providing it alone with no other files but if you use a good packager like the build-in packager in Netbeans (based on Inno Setup and Wix), javapackager, or JNDT (the next version will probably use NSIS), you can just put the native libraries into your bundle and use my workaround. You can even deploy a bundle containing an exploded JAR, i.e your bundle contains the files that are usually in the JAR(s). If your own "fat" JAR is already merged with jogamp-far.jar and if your tool preserves the location of the native libraries, deploying an exploded JAR with my workaround is not that hard for you and convenient for the end users who still have a single file to download.

Sorry to bring this old topic back up, but im sure you can help me with bundling issues. :)

I have included the jars needes to out applications fat-jar with ant (call it Client.jar) and it works fine _without_ the -Djogamp.gluegen.UseTempJarCache=false parameter. However, adding this parameter was the solution to the rare problem of slow java3d initialization, so I'd really like to use it. This is the error I get.

java.lang.UnsatisfiedLinkError: Can't load library: C:\Program Files\Company\Application\client\natives\windows-amd64\\gluegen-rt.dll

When I browse the Client.jar package with 7zip i can find all the dll's at the same location as they are located in individual native jars. I suppose my library path is limited to the folder containing Client.jar (C:\Program Files\Company\Application\client), but from the previous post I got the impression that by bundling native libraries to the Client.jar I would be spared of providing OS specific native libraries with the jar.

So - is there a way to find the natives inside the fat-jar and keep automated native deployment disabled? Modifying some build parameters to include dll's inside jars or some other method? The most annoying thing is, that when automated native development is enabled, the libraries seem to be found and extracted just fine.