tags:

views:

49

answers:

2

I have a class that calls a native function to get information about a system from its CMOS. The class has a static initialization block which loads the library containing the native function, and it looks something like this:

package lib.sysid;

public class SysId
{
    private static native int getSysIdNative();
    private static final String SYS_ID_PATH = "libsysid.so";

    static
    {
        System.load(SYS_ID_PATH);
    }

    public static int getSysIdFromCMOS()
    {
        int returnValue = getSysIdNative();
    }
}

According to my testing, the method works fine the first time I use it, but if I call the method again at a later time, the static initialization block also runs, causing an UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: Native Library libsysid.so already loaded in another classloader

How can I avoid the static initialization block from executing the System.load() method if it has already been run?

Alternatively, is there a way for me to attempt to "unload" the library if it is already loaded before calling the System.load() method again?

EDIT: Strangely enough, if I surround the System.load() call with a try-catch block, I still get an UnsatisfiedLinkError, but this time it comes from the actual call to getSysIdNative(). The error I see is the following:

lib.sysid.SysId.getSysIdNative()I

What the heck is that "I" that shows up? I've tried to attach a debugger to this code to see where the message gets populated, but so far I haven't been successful.

+1  A: 

Just a guess, but I think the only way for a single JVM to load a class (and execute its static initializers) twice is to load it with different classloaders. So there may be a second classloader involved here that you're not aware of. This would apply if a different (set of) classloader(s) is in effect the second time around.

Under a "real" operating system, java -verbose:class would give you loader messages to verify this with. I'm not sure how you'd go about verifying this on an embedded system. You could modify getSysId() to print (?) or somehow dump a reference to SysId.class.getClassLoader().

Carl Smotricz
A: 

I think @Carl is right. The only way that a static initializer can run twice in a JVM is if the class is being loaded in multiple class loaders.

lib.sysid.SysId.getSysIdNative()I What the heck is that "I" that shows up?

That's easy. The I is based on the internal representation of types in signatures that is defined by the class file format. In particular, I means the primitive int type; see Class.getName(), etc. This matches your method's return type.

(It is a little bit confusing that these primitive type names show up in application space occasionally, but they do. Another case where you can see them is when you call toString() on a class that inherits the method implementation from the Object class.)

Stephen C
That's exactly the problem I see. There is some logic in the system I am using that "reloads" all of the library files associated with the system, including my above file, but it does this through a different class loader than the one that first loads the files.
Blue