Interaction between -Djava.library.path and -javaagent (bug or feature?)
I am using the -javaagent option to load a custom class transformer which
modifies a specified method by adding a call to a native library at beginning
and at the end. I have made exactly the same modification by hand and not
used the option -javaagent:... to prove that everything works OK and there
are no obvious problems. However, when I use the -javaagent option the
native library is not loaded properly:-
"Exception in thread "main" java.lang.UnsatisfiedLikeError: no xxx in java.library.path"
at java.lang.ClassLoader.loadLibrary (ClassLoader.java:1682)
etc.
To address this I have tried adding the option -Djava.library.path=/home/xxx
which makes no difference at all. A glance at the code for loadLibrary shows
that it will follow a different path if the class loader is null. With this in mind
I have added a print statement to my test class to show the object's class
loader. If I use the -javaagent option then it is null otherwise it is
sun.misc.Launcher$AppClassLoader@56169e11.
Is deliberate that the class loader should change when instrumentation is
used? If so is it deliberate that the loadLibrary function only looks in one
place when the class loader is null to me the two policies seem to make
a problem.
Is it deliberate that the message in the exception is hardwired not mention
that it also looks in jre/lib/sparcv9 ? I know for certain that it does because
I can work around the problem putting the library here.
Is there a more elegant work around than the one I have?
