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

[Andrew John Hughes]

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.

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

> Thanks,
> Omair
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8