/usr/lib/jni not put in java.library.path

The same happens for openjdk-6-jre.
This caused eclipse and the subclipse package not to find the installed javahl (libsvn-java package).

I think for user convinience this default location /usr/lib/jni should be set as a default search path for
all java runtimes (don't now how to do this properly thow).

Best regards,
Oliver

Thanks for the report.

This has been fixed in openjdk-6-jre:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517338

Does this bug still exist in in lucid for sun java?

Yes, it still exists in lucid for sun java 6.
In eclipse, it reports the library path to be:
/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/amd64/server:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/amd64:
/usr/lib/jvm/java-6-sun-1.6.0.20/jre/../lib/amd64:
/usr/lib/xulrunner-1.9.2.3:/usr/java/packages/lib/amd64:
/usr/lib64:
/lib64:/lib:
/usr/lib

Without /usr/lib/jni .

Thanks Haggai,
Debian listed this as "won't fix" [1] for java 5, but the same should apply for java 6:

"these are binaries, and we are not allowed to ship those in modified form."

[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382686

Couldn't it be fixed somehow in a properties file, without changing the binaries? Or perhaps using a wrapper around the java binary?

Hello debian java maintainers,

The Java policy says [1]:
"If a virtual machine supports native code, it must include the
directory /usr/lib/jni in its search path for these dynamic
libraries."

openjdk6 was patched to allow looking for JNI libraries in
/usr/lib/jni in bug 517338 [2], and was fixed in openjdk-6
(6b14-1.5~pre1-5). However the bug exists in the sun java JVMs [3,4].

I know that sun java does not allow us to change the binaries, so [3]
was marked as "won't fix." I'm the maintainer of rxtx (librxtx-java)
which is jni, and some users have been complaining about how sun java
cannot see it by default[5]. What is the best way to handle this?
Should it be handled at the sun-java6 level or should I use some use
some script (postinst?) so it can work with sun java?

Thank you.

Regards,
Scott

[1] http://www.debian.org/doc/packaging-manuals/java-policy/c43.html#policy-vm
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517338
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382686
[4] https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/325506
[5] https://bugs.launchpad.net/ubuntu/+source/rxtx/+bug/380027

Le vendredi 12 novembre 2010 à 09:51 -0500, Scott Howard a écrit :
> I would to revisit this bug. I agree with the debian policy decision
> to keep compiled binaries in /usr/lib/jni/, but I'm getting frequent
> bug reports and emails form users of a library I maintain telling me
> that I installed the library to the wrong location [1-8, and personal
> correspondence]. I know we can't change the binaries, but can we
> somehow export this simple variable [9] in a wrapper so that all
> systems (that install sun-java) know to look in /usr/lib/jni? I think
> that would be a simple solution that will satisfy users so that they
> don't think our libraries are all broken.
>[9] LD_LIBRARY_PATH="/usr/lib/jni${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

On Fri, Nov 12, 2010 at 11:57 AM, Sylvestre Ledru <email address hidden> wrote:
> I agree with you we should do that.
> I had a (too) quick look on this and doing some modifications
> in /etc/java-6-sun/* might fix this bug.

That would work too, I'm not too familiar with how the sun package is
put together with the properties files in /etc, but the
java.library.path property is what should be appended (or set).

a properties file that looks something like:
# Tells java to look for JNI libraries in the Debian policy location
java.library.path=/usr/lib/jni

I don't know if we would need to do some substr magic to append the
path, or if that is typically an empty variable to begin with. I
couldn't find documentation saying whether or not it should be
appended or if it is ok to set to a single directory. I also don't
know if a user setting LD_LIBRARY_PATH on their own overwrites our
java.library.path

tags 382686 patch
thanks

On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard <email address hidden> wrote:
> I also don't
> know if a user setting LD_LIBRARY_PATH on their own overwrites our
> java.library.path
>

Setting LD_LIBRARY_PATH appends java.library.path, but passing
-Djava.library.path to java overwrites java.library.path [1]

> On Fri, Nov 12, 2010 at 11:57 AM, Sylvestre Ledru <email address hidden> wrote:
>> I agree with you we should do that.
>> I had a (too) quick look on this and doing some modifications
>> in /etc/java-6-sun/* might fix this bug.
>

sun java doesn't use a .properties file to override the system
defaults on start up. IBM's java does [2], but there is no
corresponding feature in sun java that I can find (and others
apparently can't find it either[3].)

I created a patch (attached) for the debian packaging which replicates
what is done with javaws. I have a template in debian/ which is filled
in to point to the correct directory, then is installed into
/@BASEDIR/jre/bin. The original java binary is moved to java.real and
is called by the wrapper after properly setting LD_LIBRARY_PATH

[1]
import java.util.Properties;
public class javalibraryfinder {

   public static void main(String[] args) {
       // low level classpath, includes system jars
       System.out.println( System.getProperty( "java.library.path" ) );

   }

}

showard@s-desktop:~$ java -Djava.library.path=/TEST javalibraryfinder
/TEST

showard@s-desktop:~$ LD_LIBRARY_PATH=/TEST java javalibraryfinder
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/TEST:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib

[2] http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzaha%2Fsdpropf.htm
[3] http://echelog.matzon.dk/logs/browse/java/1234393200
#java channel on freenode Feb 12,2009:

[01:43:28] <nog_lorp> is there a way I can configure JVM system
properties globally for Sun Java?
[01:44:11] <nog_lorp> IBMs java docs mentions the
SystemDefault.properties file, but that is not mentioned anywhere by
sun
[01:44:15] <nog_lorp> and doesn't work

Le mercredi 17 novembre 2010 à 10:54 -0500, Scott Howard a écrit :
> tags 382686 patch
> thanks
>
> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard <email address hidden> wrote:
> > I also don't
> > know if a user setting LD_LIBRARY_PATH on their own overwrites our
> > java.library.path
> >
>
> Setting LD_LIBRARY_PATH appends java.library.path, but passing
> -Djava.library.path to java overwrites java.library.path [1]
>
> > On Fri, Nov 12, 2010 at 11:57 AM, Sylvestre Ledru <email address hidden> wrote:
> >> I agree with you we should do that.
> >> I had a (too) quick look on this and doing some modifications
> >> in /etc/java-6-sun/* might fix this bug.
> >
>
> sun java doesn't use a .properties file to override the system
> defaults on start up. IBM's java does [2], but there is no
> corresponding feature in sun java that I can find (and others
> apparently can't find it either[3].)
>
>
>
> I created a patch (attached) for the debian packaging which replicates
> what is done with javaws. I have a template in debian/ which is filled
> in to point to the correct directory, then is installed into
> /@BASEDIR/jre/bin. The original java binary is moved to java.real and
> is called by the wrapper after properly setting LD_LIBRARY_PATH
OK. Thanks for spending some time on this.

However, I don't see this change going in Squeeze. If you are OK, I will
upload your modification as soon as Squeeze is out (and also in Ubuntu).
This will allow us some deeper testing and potential side effects.

How does it sound ?
Sylvestre

On 17.11.2010 16:54, Scott Howard wrote:
> tags 382686 patch
> thanks
>
> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard<email address hidden> wrote:
>> I also don't
>> know if a user setting LD_LIBRARY_PATH on their own overwrites our
>> java.library.path

this is incomplete; only works if the jvm is called by the java binary.

> However, I don't see this change going in Squeeze. If you are OK, I will
> upload your modification as soon as Squeeze is out (and also in Ubuntu).
> This will allow us some deeper testing and potential side effects.
>
> How does it sound ?
> Sylvestre

Sounds great - I didn't expect it to get into squeeze/ubuntu and think
it needs testing before making into a stable release.

I don't know if you saw this:

On Wed, Nov 17, 2010 at 11:24 AM, Matthias Klose
<email address hidden> wrote:
>> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard<email address hidden> wrote:
>>> I also don't
>>> know if a user setting LD_LIBRARY_PATH on their own overwrites our
>>> java.library.path
>
> this is incomplete; only works if the jvm is called by the java binary.
>

I'm seeking some more help from java people at sun one last time
before we might have to just say that an incomplete solution might be
the only policy-compliant [1] solution for a non-free package. Please,
if anyone knows of a better way let us know (the joys of non-free
packages: features can be undocumented and a mystery!). The best fix
is to use open-jdk, which I've been suggesting to users.

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9

Le jeudi 18 novembre 2010 à 09:45 -0500, Scott Howard a écrit :
> > However, I don't see this change going in Squeeze. If you are OK, I will
> > upload your modification as soon as Squeeze is out (and also in Ubuntu).
> > This will allow us some deeper testing and potential side effects.
> >
> > How does it sound ?
> > Sylvestre
>
> Sounds great - I didn't expect it to get into squeeze/ubuntu and think
> it needs testing before making into a stable release.
Indeed

>
> I don't know if you saw this:
I did.

> On Wed, Nov 17, 2010 at 11:24 AM, Matthias Klose
> <email address hidden> wrote:
> >> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard<email address hidden> wrote:
> >>> I also don't
> >>> know if a user setting LD_LIBRARY_PATH on their own overwrites our
> >>> java.library.path
> >
> > this is incomplete; only works if the jvm is called by the java binary.
> >
>
> I'm seeking some more help from java people at sun one last time
> before we might have to just say that an incomplete solution might be
> the only policy-compliant [1] solution for a non-free package.

Maybe Tom (C/C of this email) can help us here.

Sylvestre

On 17.11.2010 17:09, Sylvestre Ledru wrote:
> Le mercredi 17 novembre 2010 à 10:54 -0500, Scott Howard a écrit :
>> tags 382686 patch
>> thanks
>>
>> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard<email address hidden> wrote:
>>> I also don't
>>> know if a user setting LD_LIBRARY_PATH on their own overwrites our
>>> java.library.path
>>>
>>
>> Setting LD_LIBRARY_PATH appends java.library.path, but passing
>> -Djava.library.path to java overwrites java.library.path [1]
>>
>>> On Fri, Nov 12, 2010 at 11:57 AM, Sylvestre Ledru<email address hidden> wrote:
>>>> I agree with you we should do that.
>>>> I had a (too) quick look on this and doing some modifications
>>>> in /etc/java-6-sun/* might fix this bug.
>>>
>>
>> sun java doesn't use a .properties file to override the system
>> defaults on start up. IBM's java does [2], but there is no
>> corresponding feature in sun java that I can find (and others
>> apparently can't find it either[3].)
>>
>>
>>
>> I created a patch (attached) for the debian packaging which replicates
>> what is done with javaws. I have a template in debian/ which is filled
>> in to point to the correct directory, then is installed into
>> /@BASEDIR/jre/bin. The original java binary is moved to java.real and
>> is called by the wrapper after properly setting LD_LIBRARY_PATH
> OK. Thanks for spending some time on this.
>
> However, I don't see this change going in Squeeze. If you are OK, I will
> upload your modification as soon as Squeeze is out (and also in Ubuntu).
> This will allow us some deeper testing and potential side effects.
>
> How does it sound ?

not good. The license only allows unmodified distribution, plus it only "helps"
when calling the "java" binary, not when starting the VM in other ways.

   Matthias

On Thu, Nov 18, 2010 at 8:59 PM, Matthias Klose <email address hidden> wrote:
> not good. The license only allows unmodified distribution, plus it only
> "helps" when calling the "java" binary, not when starting the VM in other
> ways.
>
>  Matthias

If that's the way it is, then that's it.

If the license only allows unmodified distribution, is Debian allowed
to make the wrapper for java web start?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489833