Yeah, I know that modifying the system prop on the fly would not work. I read the article :) But the trick they mention is equivalent to it though.
What you are eluding in the other thread is where I'm going with this, but I'm not sure that preloading all the libraries would not result in additional issues. Anyway thanks for the discussion. If I get to continue the exploration down this path, I will report on my progress. Pascal On 2012-06-10, at 10:51 PM, BJ Hargrave wrote: > 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
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
