This content has been marked as final. Show 7 replies
Joe wrote:You have two problems - not one.
That makes sense.
The System.loadLibrary portion is in a 3rd party library which I am legally not allowed to change.
Are there any other possible ways to accomplish the loading without the library being on the java.library.path?
The library itself is calling loadLibrary(). The standard idiom is that one does that in a static block. If a static block throws an exception, any exception, then the class will not load.
Presumably the library is not checking for a duplicate library load. So your problem is that that loadLibrary() call must not throw an exception.
Thus you cannot preload the library.
Far as I can see you have the following options.
- Put it on the path.
- Create a jave exec handler (via Runtime.exec or jni), put the library on that path before you start another VM which does the real work.
- Modify the java API loadLibrary() call so it catches the dup exception, that of course requires a boot option.
The System.loadLibrary portion is in a 3rd party library which I am legally not allowed to change.So therefore you can't alter its concept of where the library actually is. So you are stuck with . or java.library.path. I believe somewhere on the PATH should also work from my dim memories of Windows DLLs but it's been a really long time ;-)