File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes JNI Question on Load/Unload library Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "JNI Question on Load/Unload library" Watch "JNI Question on Load/Unload library" New topic

JNI Question on Load/Unload library

Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
I have loaded in a library, but it was originally stored in a jar file. Because it was in the jar, I had to create a file on the hard drive and save it there. What I want is to delete that library once the program shuts down. However, I can't do this currently (deleteOnExit won't work because the JVM is still using the library).
The JVM does not offer a function unloadLibrary, but I've looked at the code they use in their native code and as far as I can see, there's nothing that will be messed up by my calling similar code. (I've posted it below with comments). However, I want to be sure. Does anyone KNOW if something will happen? If I put this in (the call to remove the library) my main class' "finalize()" method, will that be safe enough? I know that finalize isn't guaranteed to be called, but that's better than nothing for me.

So normally, I'd just call FreeHandle, but since it was loaded by the VM I have to clean it out from there. Anyone know if there's safe/better way to do this?
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
OK, forget all that, I may have found an all Java solution, but I'm not sure.
Ok, the class ClassLoader has a static class NativeLibrary which basically
is a descriptor for every native library loaded (holds its name, what class
loaded it, its handle, stuff like that). This is stored in a private Vector
called nativeLibraries. Since it's private, extending ClassLoader (or
rather SecureClassLoader or URLClassLoader) won't give me access, but
actually I think that's totally fine, and here's why:
When loading normal libraries, I'll delegate to super.loadLibrary(), etc.
However, loading libraries form a jar are slightly different. I don't just
want to load the library, I want to create a file on disk, save the
jarentry data (i.e. the library) to there, then on exit, unload it and then
delete it from the file. SO I'm thinking that I can override loadLibrary
and delegate to the super class, if it can't find it, then I try my own
loadLibraryFromJar. That method saves it to a private Vector
nativeLibrariesFromJars. Now the ClassLoader class happens to unload
everything in finalize(), so I would have finalize in my class and unload
the library from there (similarly to how they do it). Does anyone see a
problem with this? Is there some logic that's a bit off? Areas that might
cause problems?
The one I can see is that any class not loaded by my classloader will not
be able to see the loaded library. A possible solution (?) is that when I'm
loading by jar, I save it to disk and then delegate with that path to the
system classloader. then in my finalize() I call the super class' finalize
and then delete after that's done. Will this work? Anyone see problems with
this? If it works, it seems MUCH, MUCH safer/cleaner than using JNI to do
all this.
I agree. Here's the link:
subject: JNI Question on Load/Unload library
It's not a secret anymore!