Project Jigsaw goals and requirements

[Richard S. Hall]

On 06/11/2011 07:34 PM, Michael Bien wrote:
> On 06/02/2011 05:30 PM, Richard S. Hall wrote:
>> On 6/2/11 11:07, Benoît Thiébault wrote:
>>> Hi everyone,
>>>
>>> This discussion about Jigsaw requirements is very interesting and
>>> constructive and I am really looking forward to see what Java modules
>>> will be capable of.
>>>
>>> Just to add my own set of remarks, I would like to point that support
>>> for native librairies is very important and should not be neglected.
>>>
>>> In OSGi, it is already feasible, but it is poorly documented and has
>>> some very strong constraints (as explained here:
>>> http://dev.artenum.com/blog/ben/posts/osgi_vtk_and_macosx). One of the
>>> most annoying things is to have to explicitly call System.loadLibrary()
>>> for every shared library and its dependencies to tell OSGi framework
>>> what .so (.dll or .jnilib) files to extract from the jar bundle.
>>
>> To be precise, this is not really an OSGi issue, but a more general 
>> one about native library dependencies...Java can only intercept 
>> native library load requests coming from Java code. Arbitrary native 
>> libraries that have dependencies on other native libraries cannot be 
>> intercepted by Java and automatically loaded by the JVM. The 
>> procedure you describe above is simply a workaround.
>
> there is a second problem which native libs: If i remember correctly 
> you can load a lib only once per JVM instance but the scope of the lib 
> is still the classloader. So what everyone did before java 6 got 
> improved jnlp support for native libs was to copy the lib into /tmp, 
> rename it and load it from there. Thats also one of the reasons why 
> there is/was a master-slave jvm when running applets in the new 
> browser plugin as far as I know.
>
> Would be nice if jigsaw could handle that properly this time. E.g 
> allowing two versions of the same library in one JVM etc.

That was not my understanding. From what I understand, a given native 
library can only be associated with a single class loader. Thus, if you 
want to load the same native library in more than one class loader, it 
must be loaded from a unique location in the file system (i.e., it 
doesn't necessarily need to be renamed, but its absolute path must be 
different).

-> richard

>
> best regards,
> michael
>