Bug 744672 - unix.jar cannot be used without fiddling with java.library.path
Summary: unix.jar cannot be used without fiddling with java.library.path
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libmatthew-java
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Omair Majid
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-10 06:08 UTC by David Tardon
Modified: 2011-11-05 01:35 UTC (History)
2 users (show)

Fixed In Version: libmatthew-java-0.8-2.fc16
Clone Of:
Environment:
Last Closed: 2011-11-05 01:35:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
reproducer (226 bytes, text/x-java)
2011-10-10 06:08 UTC, David Tardon
no flags Details
fix it (785 bytes, patch)
2011-10-10 06:09 UTC, David Tardon
no flags Details | Diff

Description David Tardon 2011-10-10 06:08:49 UTC
Created attachment 527154 [details]
reproducer

Description of problem:
Because this package chooses to put dynamic libraries into /usr/lib*/libmatthew-java, unix.jar and cgi.jar are not usable without extending java.library.path . AFAICS there is no automatic way to do this, e.g., by dropping a file somewhere in /etc/java (and if there were one, I would expect this package to be using it already), so it must be done on command line, e.g. -Djava.library.path=/usr/lib64/libmatthew-java . Unfortunately this is only possible if one has control over the command line. If the libraries are simply put into /usr/lib*, it will work without any additional hassle.

Version-Release number of selected component (if applicable):
libmatthew-java-0.8-1.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. get the attached reproducer
2. javac -cp /usr/lib64/libmatthew-java/unix.jar UnixTest.java
3. java -cp .:/usr/lib64/libmatthew-java/unix.jar UnixTest
  
Actual results:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no unix-java in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
	at java.lang.Runtime.loadLibrary0(Runtime.java:840)
	at java.lang.System.loadLibrary(System.java:1047)
	at cx.ath.matthew.unix.UnixSocket.<clinit>(UnixSocket.java:40)
	at UnixTest.main(UnixTest.java:7)

Expected results:
no exception

Additional info:
Because of this, dbus-java (and possible other packages using socket.jar or cgi.jar) Just Don't Work(TM).

Comment 1 David Tardon 2011-10-10 06:09:40 UTC
Created attachment 527155 [details]
fix it

Comment 2 Omair Majid 2011-10-11 20:20:44 UTC
Thanks for reporting the bug (and instructions to reproduce it!). 

The fix that you posted is not quite right; the java packaging guidelines explicitly talk about installing jars and so's to %{_libdir}/%{name}. libmatthew-java had a fix for this, but it seems to have been accidentally dropped during a recent package update. Sorry :(

I have a fix in line, but I am waiting for more testing. Can you test if the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=3423971 solve the problem for you? Thanks.

Comment 3 David Tardon 2011-10-12 05:36:13 UTC
The package has evidently been built by javac 1.7 with -target 1.7, so it does not work here:

Exception in thread "Thread-39" java.lang.UnsupportedClassVersionError: cx/ath/matthew/unix/UnixSocket : Unsupported major.minor version 51.0

But after rebuild from source it works finė.

Comment 4 David Tardon 2011-10-12 05:44:59 UTC
(In reply to comment #2)
> The fix that you posted is not quite right; the java packaging guidelines
> explicitly talk about installing jars and so's to %{_libdir}/%{name}.
> libmatthew-java had a fix for this, but it seems to have been accidentally
> dropped during a recent package update. Sorry :(

IMHO the "Rationale" for https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI does not rationalize anything. The item makes the guidelines longer and complicates packagers' work for no visible gain, it feels like it is there just "because we can do it". I personally would ignore it, but YMMV.

Comment 5 Omair Majid 2011-10-12 16:33:25 UTC
(In reply to comment #3)
> The package has evidently been built by javac 1.7 with -target 1.7, so it does
> not work here:
> 
> Exception in thread "Thread-39" java.lang.UnsupportedClassVersionError:
> cx/ath/matthew/unix/UnixSocket : Unsupported major.minor version 51.0

Oh, yes. Sorry, I had forgotten that OpenJDK7 is the default JDK in rawhide :(

> But after rebuild from source it works finė.

Thanks for testing! I will try and push out the fix ASAP.

(In reply to comment #4)
> IMHO the "Rationale" for
> https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI
> does not rationalize anything. The item makes the guidelines longer and
> complicates packagers' work for no visible gain, it feels like it is there just
> "because we can do it". I personally would ignore it, but YMMV.

Perhaps you might want to contact the folks at Java-SIG? I am quite sure they would be happy to improve the packaging guidelines and address any issues.

Comment 6 Fedora Update System 2011-10-13 22:19:19 UTC
libmatthew-java-0.8-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/libmatthew-java-0.8-2.fc16

Comment 7 Omair Majid 2011-10-13 22:22:50 UTC
Adding Alex.

Alex, could you please test that this works for you?

Comment 8 Fedora Update System 2011-10-15 14:29:30 UTC
Package libmatthew-java-0.8-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libmatthew-java-0.8-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14334
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2011-11-05 01:35:50 UTC
libmatthew-java-0.8-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.