I don't think modifying java.library.path in the fly will work. See http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/
Like I said, native code support in Java kind of sucks. I would hope that Java 8 will improve things since Jigsaw will slam into this as well. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Pascal Rapicault <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 2012/06/10 20:29 Subject: Re: [equinox-dev] looking up binaries Sent by: [email protected] The suggested approach would work but is rather painful. I have about 50 bundles delivering legacy native code so making sure that there is java code initializing all the libs does not seem like it would work all that well, and I'm not sure that I would not end with cyclic dependencies. At this point I have a script that extracts all the binaries into a lib folder and just set the os level library path... So much for modularity. I was hoping that with the ability to change the java.library.path dynamically at runtime[1] and the manifest information pertaining to native code, it would be possible to dynamically set the java.library.path upon loadLibrary to cause the right libs to be part of the library path. What do you think? Pascal [1] - http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/ On 2012-06-10, at 5:23 PM, BJ Hargrave wrote: 'cause that is the way it was designed in Java? System.loadLibrary is typically called from some class' static initializer to define the native methods of the class. System.loadLibrary calls ClassLoader.findLibrary to request advice in locating the native library. For bundle class loaders, this can then provide the location of the native library mentioned in the bundle's Bundle-NativeCode manifest header. In your example, since a class in bundle 1 has a static initializer calling System.loadLibrary("1"), then that code needs to first trigger a class loader from bundle 2 where that class' static initializer calls System.loadLibrary("2"). This will then make sure lib2.so is loaded before lib1.so. In general, the native code support in Java is really only useful for loading JNI native libraries. How the dependencies of the JNI native libraries are met is not addressed. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Pascal Rapicault <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 2012/06/10 16:48 Subject: [equinox-dev] looking up binaries Sent by: [email protected] Hey, I have a situation where the binaries for my application are spread across multiple bundles and those libraries depend on each others. For example, I have bundle1 that carries lib1.so and I have bundle2 that carries lib2.so, and bundle1 depends on bundle2. When I try to load lib1.so if lib2.so has not yet been loaded, then the loading of lib1 will fail. Is there a fundamental reason why we loading of the libraries could mimic the loading of classes? Thx Pascal _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
