jogamp - Re: ZipException when loading native jars

jogamp › jogl

Re: ZipException when loading native jars

Posted by ryanmohr on Dec 04, 2012; 9:14pm
URL: https://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4027400.html

Just about finished with my loader but ran into a little hiccup. When jogamp.gluegen.UseTempJarCache is false the Platform class expects the library to exist in java.library.path. Since the path can't be modified at runtime this severely limits our loading options. I was able to work around it but the loader design is not as clean as it could be because of this restriction.

Would it be alright to add a new property ("jogamp.gluegen.LoadLibraries", defaults to true) that when false causes the Platform class to assume the libraries have already been loaded? That way in special cases the libraries can be loaded based on the discretion of the programmer and the Platform class can just relax.

On Tue, Dec 4, 2012 at 9:59 AM, Ryan Mohr <[hidden email]> wrote:

whereas Java Web Start is reliable enough to do something similar, it's even better for updates

In theory yes. In practice, not even close. We've used web start to deploy our application for the past ten years and we're finally giving up on it. We've repeatedly been bitten by signing issues, offline issues, missing desktop icons, broken file associations... all the kinds of things our customers expect to just work. It's great for little hobby projects but just doesn't make the cut in production.

Our entire application is less than 10mb. Not an issue to have to redownload, especially since it happens in the background automatically.

Why not helping us to fix this bug? It would benefit to the whole community and you would not have to maintain a separate loader alone.

I took a look at the source and it was too messy for me to want to tinker with. Plus there is the issue of what happens if the jars can't be unzipped to the tmp directory for whatever reason (you wouldn't believe the shape some of our customers computers are in). I'll be open sourcing my custom loader solution as its own project that can be used for any java projects that need to load or execute platform specific code and libraries.