| 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.
--
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.
--
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
|
