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

[Omair Majid]

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.

More importantly, can I take this to mean that violating (what I think 
is) the spec is ok in this case?

Thanks,
Omair