[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] looking up binaries

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
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788






From:        Pascal Rapicault <pascal@xxxxxxxxxxxxx>
To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date:        2012/06/10 20:29
Subject:        Re: [equinox-dev] looking up binaries
Sent by:        equinox-dev-bounces@xxxxxxxxxxx





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
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788







From:        
Pascal Rapicault <pascal@xxxxxxxxxxxxx>
To:        
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date:        
2012/06/10 16:48
Subject:        
[equinox-dev] looking up binaries
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx






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

equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list

equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev