Ubuntu
imagej package

ImageJ chooses wrong java home

Bug #294753 reported by Peter Husen on 2008-11-06

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	imagej (Debian)	Fix Released	Unknown	debbugs #505315
	imagej (Ubuntu)	Fix Released	Undecided	Unassigned

Bug Description

ImageJ fails to run on an amd64 system if ia32-sun-java6-bin is installed. It fails with the error message
> Running a 64-bit JVM is not supported on this platform.
This seems to be due to the script /usr/bin/imagej setting JAVA_HOME by
JAVA_HOME=$(/usr/sbin/update-java-alternatives -l java-6-openjdk | head -1 | cut -d' ' -f 3)
i.e. the top line returned from 'update-java-alternatives -l'. This happens to be ia32-java-6-sun, even though /etc/alternatives/java points to /usr/lib/jvm/java-6-openjdk/jre/bin/java. The script then finds out using 'uname -m' that it is a 64 bit architecture, and therefore passes '-d64' to java. This would work on a 64 bit jvm, but not on the 32 bit jvm chosen by the script.

I guess update-java-alternatives is not the correct way to determine the default java home. I don't know the correct approach, but this seems to work for me:
JAVA_HOME=$(dirname $(dirname $(dirname $(readlink /etc/alternatives/java))))

Also, I guess the script strictly should make sure it's a 64 bit jvm instead of just using 'uname -m'

Related branches

lp:ubuntu/karmic/imagej

Revision history for this message

Peter Husen (phusen) wrote on 2008-11-06:

imagej_1.40a-1ubuntu2.debdiff Edit (879 bytes, text/plain)

Tried to make a patch including my fix. I have no experience writing patches though, so I probably did something wrong. Also I am not sure, my fix is the best one.

Revision history for this message

mercutio22 (macabro22) wrote on 2008-11-18:

Hi I can confirm this bug using intrepid ibex amd64.

Changed in imagej:
status:	New → Confirmed

Bug Watch Updater (bug-watch-updater) on 2009-03-10

Changed in imagej:
status:	Unknown → New

Revision history for this message

linuxed (linuxed) wrote on 2009-03-23:

I can confirm this bug in ubuntu 8.10 64-bit. On my system I had manually installed the latest jre (1.6.0_14) from Sun into the following directory.

/usr/lib/jvm/jre1.6.0_14

I then added a new java alternative and set it as the default jre using the following.

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jre1.6.0_14/bin/java" 1
sudo update-alternatives --set java /usr/lib/jvm/jre1.6.0_14/bin/java

To get imagej working with my jre I used a similar command to the one in the patch above. In my case I didn't require the third "dirname" command.

$(dirname $(dirname $(readlink -e /usr/bin/java)))

I'm not sure whether it's better to use /usr/bin/java or /etc/alternatives/java since they both point to the same location.

Revision history for this message

XXarles (carlosbm) wrote on 2009-05-25:

It also happens to me and I'm using the 32 bit version (Ubuntu 8.10).
My java -showversion:

Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

The error it throws:

Exception in thread "null" java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-cacao/jre/lib/i386/motif21/libmawt.so

Changing JAVA_HOME solves as shown solves the problem.

Revision history for this message

Onkar Shinde (onkarshinde) wrote on 2009-09-24:

The bug is fixed in imagej version 1.43b-1 which is available in karmic.

Changed in imagej (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

Peter Husen (phusen) wrote on 2009-09-24: Re: [Bug 294753] Re: ImageJ chooses wrong java home

No it's not fixed. The line that determines the java home is still the
same:
JAVA_HOME=$(/usr/sbin/update-java-alternatives -l | head -1 | cut -d'
' -f 3)
i.e. still the first line from update-java-alternatives -l, which is not
necessarily the configured alternative. I just installed 1.43b-1 by
installing ia32-sun-java6-bin, and it still fails in the way I
originally described (with the message "Running a 64-bit JVM is not
supported on this platform."), since it (wrongly) chooses the 32-bit jvm
and tries to use it in 64-bit mode.

$ update-alternatives --display java
java - status is manual.
link currently points to /usr/lib/jvm/java-6-sun/jre/bin/java
/usr/lib/jvm/java-gcj/jre/bin/java - priority 1042
slave java.1.gz: /usr/lib/jvm/java-gcj/man/man1/java.1.gz
/usr/bin/gij-4.2 - priority 42
slave java.1.gz: /usr/share/man/man1/gij-4.2.1.gz
/usr/lib/jvm/java-6-sun/jre/bin/java - priority 63
slave java.1.gz: /usr/lib/jvm/java-6-sun/jre/man/man1/java.1.gz
/usr/lib/jvm/java-6-openjdk/jre/bin/java - priority 1061
slave java.1.gz: /usr/lib/jvm/java-6-openjdk/jre/man/man1/java.1.gz
/usr/bin/gij-4.3 - priority 43
slave java.1.gz: /usr/share/man/man1/gij-4.3.1.gz
/usr/lib/jvm/ia32-java-6-sun/jre/bin/java - priority 63
slave java.1.gz: /usr/lib/jvm/ia32-java-6-sun/jre/man/man1/java.1.gz
Current `best' version is /usr/lib/jvm/java-6-openjdk/jre/bin/java.

$ update-java-alternatives -l
ia32-java-6-sun 63 /usr/lib/jvm/ia32-java-6-sun
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun
java-gcj 1042 /usr/lib/jvm/java-gcj

Notice how the first item in the latter output does not match the
currently configured java alternative.

Revision history for this message

Onkar Shinde (onkarshinde) wrote on 2009-09-24:

Looks like even though Debian changelog says tgis bug is fixed, it is actuakky not. I will also reopen he Debian bug.

Changed in imagej (Ubuntu):
status:	Fix Released → Confirmed

Bug Watch Updater (bug-watch-updater) on 2009-10-07

Changed in imagej (Debian):
status:	New → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-10-08:

This bug was fixed in the package imagej - 1.43b-1ubuntu1

---------------
imagej (1.43b-1ubuntu1) karmic; urgency=low

  * debian/imagej.sh
    - Backport the fix for JVM selection from Debian package. Thanks to Peter
      Husen for original suggestion and following throuh the regression report
      in current version in Debian/Ubuntu. (LP: #294753)

-- Onkar Shinde <email address hidden> Fri, 09 Oct 2009 01:17:09 +0530

Changed in imagej (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

jmrk (joergen-kornfeld) wrote on 2010-05-31:

Hm, might be broken in Lucid (again?).. Not sure yet, because I fiddled with the launcher in Karmic (at least did not work there for me).

Revision history for this message

Peter Husen (phusen) wrote on 2010-05-31:

#10

I believe they reverted the fix according to this bug report

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558222

See also
http://svn.debian.org/wsvn/debian-med/trunk/packages/imagej/trunk/debian/imagej.sh?rev=4423&sc=0

I guess this bug report (and the Debian one) should be reopened since
the original problem remains, but I am getting a little tired of this,
and it works for me currently due to my current set of installed jdks.

man, 31 05 2010 kl. 14:47 +0000, skrev jmrk:
> Hm, might be broken in Lucid (again?).. Not sure yet, because I fiddled
> with the launcher in Karmic (at least did not work there for me).
>