dll "Access is denied" vs "Can't load library"

It appears that there is a problem with the way both jogl and webstart deal with dll files.

If you I let jogl to deal with dll some of customers report this exception:

java.lang.UnsatisfiedLinkError: C:\Users\<user>\AppData\Local\Temp\jogamp_0000\file_cache\jln6017272868593155272\jln2310512220959375414\gluegen-rt.dll: Access is denied

If I used System.setProperty("jogamp.gluegen.UseTempJarCache", "false") to disable jogl's way of handling dll, then it fixes the problem with above exception for my customers, but some other customers who didn't have any problem previously now get the following exception:

java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\<user>\Desktop\gluegen-rt.dll

It appears that none of the above methods is perfect. Perhaps you could modify your jogl jar extract method so that if it fails, instead of throwing the "Access is denied" exception, it continues normally (with just a warning) so that webstart nativeLib could give it a try too.

On 03/26/2015 06:56 PM, runiter [via jogamp] wrote:
> It appears that there is a problem with the way both jogl and webstart deal
> with dll files.
>
> If you I let jogl to deal with dll some of customers report this exception:
>
> java.lang.UnsatisfiedLinkError:
> C:\Users\<user>\AppData\Local\Temp\jogamp_0000\file_cache\jln6017272868593155272\jln2310512220959375414\gluegen-rt.dll:
> Access is denied
>

I doubt this happens w/ JOGL 2.3.0,
since we test executable access of temp folder quite excessive now, see:

<https://jogamp.org/bugzilla/show_bug.cgi?id=1108#c6>
<http://jogamp.org/git/?p=gluegen.git;a=commit;h=181dc8ae227cd5cbecf60ab8d973bb8eef7c45f0>

However .. if no temp folder could be found,
GlueGen/JOGL will fail of course!

Please retest w/ 2.3.0 ..

~Sven

I agree with Sven.

When you disable the automated native library loading, you have to set the Java library path correctly, please look at the JOGL user's guide. Moreover, this kind of mechanism isn't specific to JOGL, LibGDX and JMonkeyEngine do something similar. The "nativeLib" feature of Java Webstart is already broken too as it doesn't work in some cases if the end user disables the local cache or if it is too small. Finally, Java Webstart is more or more broken as time goes by, I advise you to plan to look for an alternative, you could package your application as a self-contained native application bundle and implement your own update mechanism.