Windows temp directory not cleaned up when program messes with classpath

[mabruce]

I'm calling code through javacpp in a plugin written for ImageJ/Fiji. Fiji, unfortunately, uses a native binary to startup the Java call and forces everything through its own launcher. This launcher in turn call everything else nicely, but as far as System.getProperty("java.class.path") is concerned, only that launcher's jar is on the classpath. On Windows, this results in the javacpp Loader class being unable to tie into the shutdown hook and clean up the temp directories (since the ImageJ launcher doesn't bother looking for the javacpp jar). To alleviate this, could line 572 in Loader.java be changed from:

command.add(System.getProperty("java.class.path"));

to

command.add( (new File(Loader.class.getProtectionDomain().getCodeSource().getLocation().toURI())).toString() );

That long and ugly string of commands locates the jar containing the javacpp Loader (and converts it so system-native format). I've been using a similar bit of code to locate the jar with my own code and write files to the same directory.

I can put the change in a pull request if you think it's a good modification.

[saudet]

Sounds good! Yes, please do send a pull request. Thanks!!

[mabruce]

Cleans up the temp files every time I've checked, so I'll mark this closed.