[RFC] JNLP: jars with native libraries in incorrect locations

[Omair Majid]

On 06/22/2010 06:22 PM, Andrew John Hughes wrote:
> On 22 June 2010 22:08, Omair Majid<omajid at redhat.com>  wrote:
>> On 06/22/2010 04:47 PM, Andrew John Hughes wrote:
>>>
>>> On 22 June 2010 19:06, Omair Majid<omajid at redhat.com>    wrote:
>>>>
>>>> On 06/15/2010 09:42 AM, Omair Majid wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I recently ran into a problem with SweetHome3D [1] not working under
>>>>> Netx. The jnlp file contains no 'nativelib' elements which initially led
>>>>> me to believe that it contains no native code. However, one of the jars
>>>>> it references [2] contains native code under /linux/x64/. Both of these
>>>>> things (no nativelib element and placing .so's anywhere other than under
>>>>> /) seem to go against the developer guide's guidelines. Of course,
>>>>> without reading the JSR, I can not say if this is against the JNLP spec
>>>>> or not.
>>>>>
>>>>> That said, since the Sun/Oracle Webstart works with SweetHome3D, Netx
>>>>> should work too. The attached patch modifies Netx so that it always
>>>>> tries to look for .so's (placed anywhere) in jar files. If it finds
>>>>> them, it activates them as if the .so's were in a nativelib jar.
>>>>>
>>>>> Any thoughts or comments?
>>>>>
>>>>> Cheers,
>>>>> Omair
>>>>>
>>>>>
>>>>> [1] http://www.sweethome3d.com/SweetHome3D.jnlp
>>>>> [2] http://www.sweethome3d.com/lib/linux/x64/java3d.jar
>>>>
>>>> Anyone?
>>>>
>>>
>>> Sorry, didn't see this until your ping.
>>>
>>> The code you have to find the file component of the path could be more
>>> portably written as new File(e.getName()).getName():
>>> http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#getName%28%29
>>>   That also deals with the issue of the path ending in a '/', which
>>> would currently result in an IndexOutOfBoundsException.
>>>
>>
>> Ah, that sounds just like what I was looking for. Thanks. Still, this code
>> only executes if the entry is not a directory, so the exception should never
>> happen (at least on a unix-like system). But your way makes a lot more sense
>> :)
>>
>>> Sadly I can't see a method for obtaining the dynamic library name
>>> extension (System has mapLibraryName to do x ->    x.so, but nothing to
>>> check an existing path; maybe something to suggest upstream).
>>> Checking for .so, .dll and .dylib should cover most cases.
>>>
>>
>> Yup, I was hoping to find something in the JRE to check for a library name
>> but couldn't. I guess I will manually add checks for .so, .dll and .dylib.
>> Do you know of any reference where I could find a list of possible
>> extensions? I ask because I have never seen .dylib before, and I would hate
>> to miss other possible library extensions.
>>
>
> There's http://en.wikipedia.org/wiki/Dynamic_libraries#Naming
>
> Most systems are .so (GNU/Linux, Solaris, *BSD).  The exceptions are
> MacOS X which renames them to .dylib (though they are essentially the
> same thing) and also has bundles of them which we should also probably
> allow for (.framework as mentioned in the link), along with Windows
> which uses the .dll system as it always has to be different.
>

I added ".so", ".dylib", ".jnilib", ".framework" and ".dll". Apple's JNI 
documentation suggests they prefer people using jnilib for JNI libraries.

>> More importantly, can I take this to mean that violating (what I think is)
>> the spec is ok in this case?
>>
>
> I'd say their proprietary implementation is the spec. for all intents
> and purposes, and if it works with that so be it.
>

How about this version of the patch?

Thanks,
Omair
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icedtea6-jnlp-bad-native-library-jars.patch
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20100623/1615a2f4/icedtea6-jnlp-bad-native-library-jars.patch