[BridJ, OSGi] Platform.DeleteFiles: process uses java.class.path, finds equinox.launcher.jar in equinox/OSGi context and fails

[mfriedemann]

I am using BridJ in an equinox/OSGi context and while it works fine, it requires a bit of additional effort for the setup and cleanup steps.

I finally got around to look into the cleanup, which, under the equinox/OSGi context, failed to remove the temporary files and their target directory.
The issue is that while it identifies the files and marks them for deletion to be completed in the shutdown hook, the process it starts uses the existing java.class.path environment variable.
For equinox/OSGi, this variable is, however, set to the equinox launcher jar file, which the Platform.DeleteFiles class is obviously not a part of.

For now, I am working around this specific issue by setting up another shutdown hook that first finds the proper bridj jar from the OSGi bundle and then sets the java.class.path variable to that jar file.

I would like to propose an enhancement (either of BridJ's OSGi specifics or to BridJ in general), that actually tries to find the bridj.jar itself and uses it as the sub-process' classpath.

Regards,
Marko

[MichaelEnke]

Another way to circumvent the deletion problem (on windows only, I guess) would be to use the envirnoment variable or property to point to bridj.dll or bridj.so. This requires to have the library extracted manually before.
It would be better to call the createTempDir() (in Platform.java) not in the static block (which executes always) but in initLibrary() when forceLibFile is null.
That would avoid the temp file creation and deletion.

[mfriedemann]

Hm, I am not sure this is possible.
AFAICS dlopen/LoadLibrary can't load native library files from archive files, which makes the extraction into a temporary directory and its deletion upon exiting mandatory.

M.

[MichaelEnke]

I meant and wrote that manual extraction is required. As it is now, without having the bridj jar in the classpath property (which is the case for projects building its classpath themselves), the temp dirs are not deleted.