Ubuntu

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

Reported by Stephane Galland on 2009-02-04
84
This bug affects 14 people
Affects Status Importance Assigned to Milestone
openjdk-6 (Debian)
Fix Released
Unknown
sun-java6 (Debian)
Won't Fix
Unknown
sun-java6 (Ubuntu)
Undecided
Unassigned

Bug Description

The standard Debian rules about Java introduce /usr/lib/jni as the location of the JNI libraries.

This path is not present in the default Sun JRE library path.
The only way to put /usr/lib/jni in java.library.path is to explicitly use the -D command line option or to set LD_LIBRARY_PATH environment variable.

Because the sun-java6 package is based on binaries, could it be possible to put a wrapping script which is setting the LD_LIBRARY_PATH according to the Debian rules? See attachment for an example. This script could be link as an alternative in place of all the JRE's binaries.

The OpenJREs have been requested to add /usr/lib/jni directory inside the default library path on Debian-like systems.

Best regards,
Stéphane

Stephane Galland (galland) wrote :

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

Scott Howard (showard314) wrote :

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?

Haggai Eran (haggai-eran) wrote :

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 .

Changed in openjdk-6 (Debian):
importance: Unknown → Undecided
status: Unknown → New
status: New → Fix Released
Scott Howard (showard314) wrote :

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

Haggai Eran (haggai-eran) wrote :

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

Changed in openjdk-6 (Debian):
importance: Undecided → Unknown
status: Fix Released → Unknown
Changed in sun-java6 (Debian):
status: Unknown → Won't Fix
Scott Howard (showard314) wrote :

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

Scott Howard (showard314) 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
>

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

Sylvestre Ledru (sylvestre) 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 ?
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

Sylvestre Ledru (sylvestre) wrote :

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

Matthias Klose (doko) wrote :

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

Scott Howard (showard314) wrote :

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

Changed in openjdk-6 (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.