Posted by Sven Gothel on Feb 12, 2012; 9:42pm
URL: https://forum.jogamp.org/JOGL-upgrade-fails-tp3728805p3738528.html

On 02/12/2012 10:26 PM, Wade Walker [via jogamp] wrote:
>
>
>
> One possible disadvantage of this system is that when you upgrade your JOGL
> JARs, the DLL caching system has to be smart enough to overwrite the old
> DLLs (but it can't just always overwrite them, since this would slow down
> startup times). There can also be problems finding a directory where the
> user has write permissions, depending on the OS and how the user permissions
> are set up. But once these problems are solved, it's a good system.

We have different levels of cache to consider here.

GlueGen Jar Cache:

The new cache with GlueGen I have added always starts from scratch
with a new JVM / ClassLoader, this is a requirement to native libraries
and it's classloader. We have a JVM level folder and within a classloader one.

The caches will be removed at startup when no lock is hold on it.

+++

Java (RT) Jar Cache (Network .. etc):

In case the base URL of the source of eg jogl.all.jar
is a network resource like http (Applets etc),
Java itself caches it and usually allows fast access
when the remote source has not changed.
However .. I have experienced a bug here (OS X I guess),
where the network cache returned an old JAR file.

+++

In conclusion I think our Jar Cache has no big side effects
or downsides. The same semantics was used within the AppletLauncher
and it worked quite well for a long time.

Wade and myself were able to fix a few 'odds' already.
Since it is already the default and 'in production' for a few month,
we haven't heard about complains so far.

~Sven