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

[Omair Majid]

On 06/23/2010 05:54 PM, Andrew John Hughes wrote:
> On 14:00 Wed 23 Jun     , Omair Majid wrote:
>> 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?
>>
>
> Looks good.  I like the 1.5 updates too; there's a lot of that needs fixing in NetX
> from what I've seen.  I assume nativeCounter is an unused variable?
>

Yup, there are a ton of problems. I am hoping to go through and fix as 
much as I can. As far as nativeCounter is concerned, I cant find a 
record of it ever being used.

Cheers,
Omair