Bug 744672

Summary: unix.jar cannot be used without fiddling with java.library.path
Product: [Fedora] Fedora Reporter: David Tardon <dtardon>
Component: libmatthew-javaAssignee: Omair Majid <omajid>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: akurtako, omajid
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libmatthew-java-0.8-2.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-05 01:35:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer
none
fix it none

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.