Library is not deleted from /tmp on JVM exit

[blueberry]

This is an issue only if JOCLBlast is updated - the old native libraries stay in the tmp folder and have to be deleted manually - otherwise they will be used even when JVM is restarted.

This is not a huge problem, but should be mentioned somewhere. It is very important during the development.

[gpu]

Apologies that I did not mention this, even though I also stumbled over this recently.

This is known and, to some extent, "intentional": The reason of why they are not deleted is that under windows, it's not directly possible to delete a library file (DLL) as long as it is still loaded in the JVM*. Things like File#deleteOnExit or some ShutdownHook magic won't do it. In any case, even these would only work if the JVM exited normally.

So when the version number does not change (e.g. by pulling and updating only a changed SNAPSHOT / development version, the temp file has to be deleted manually to make sure that the "new" file is loaded. Therefore, during development, I usually place the binaries into the java.library.path. The process in the LibUtils is:

• It will first try to load them from the local file, using System.loadLibrary
• If this fails, it will try to load the right library (with the current version) from the temp-folder
• If the temp-file does not exist, it will be created by unpacking the native from the JAR and writing it to the temp-folder

so when the library with the current version is always loaded from a local file (or not contained in the JAR at all) it will never be written to the temp-folder.

---

* There was a related forum thread a while ago. And there are approaches for solving this. I tried this with the https://github.com/gpu/JOCL/blob/master/src/main/java/org/jocl/LibTracker.java , but this is not activated right now, because it has to use some nasty reflection hacks to make sure that the file can be deleted. It seemed too fragile for me to enable this by default, also because I can hardly test this on all possible OSes and JVMs.

However, if you have the chance to specify JVM parameters, you can try adding

java -DuniqueLibraryNames=true TheApplication

as a parameter during the tests. Then, it will assign a unique name to the library at each invocation, and try to delete it when the JVM exits. Note, however, that this is somewhat experimental, and has not been tested extensively (particularly, not together with the "depdendency loading" that was added recently).