I experienced a change in behaviour when upgrading my system.
Apparently Apple's 'java' command now cares about the JAVA_HOME
variable more than it used to.
I normally set JAVA_HOME to point at my local soylatte directory
since I can't use Apple's Java 6 on my 32-bit machines and I want the
same ant compilation environment everywhere, but when I do that, I
can't execute the 'java' command at all. It just gives me:
$ java -version
Error: could not find libjava.dylib
Error: could not find Java 2 Runtime Environment.
$ java -d32 -version
Error: could not find libjava.dylib
Error: could not find Java 2 Runtime Environment.
$ java -d64 -version
Running a 64-bit JVM is not supported on this platform.
(with JAVA_HOME=/Users/erik/bin/soylatte16-i386)
This is because the /usr/bin Java tools are attempting to re-exec what
they find in $JAVA_HOME with the same architecture they were launched
as (but will fall back to any available archtecture). I'm guessing
that the SoyLatte tools must have 2-way universal command-line tools
in soylatte16-i386/bin, but only i386 dylibs, so the initial launch as
x86_64 just works, but fails to load the libjava.dylib.
No, the soylatte tools are in fact all non-fat i386 binaries.
---
$ pwd
/Users/erik/bin/soylatte16-i386/bin
$ lipo -info *
Non-fat file: appletviewer is architecture: i386
Non-fat file: apt is architecture: i386
Non-fat file: extcheck is architecture: i386
Non-fat file: idlj is architecture: i386
Non-fat file: jar is architecture: i386
Non-fat file: jarsigner is architecture: i386
Non-fat file: java is architecture: i386
Non-fat file: javac is architecture: i386
Non-fat file: javadoc is architecture: i386
Non-fat file: javah is architecture: i386
Non-fat file: javap is architecture: i386
Non-fat file: jconsole is architecture: i386
Non-fat file: jdb is architecture: i386
Non-fat file: jhat is architecture: i386
Non-fat file: jinfo is architecture: i386
Non-fat file: jmap is architecture: i386
Non-fat file: jps is architecture: i386
Non-fat file: jrunscript is architecture: i386
Non-fat file: jsadebugd is architecture: i386
Non-fat file: jstack is architecture: i386
Non-fat file: jstat is architecture: i386
Non-fat file: jstatd is architecture: i386
Non-fat file: keytool is architecture: i386
Non-fat file: native2ascii is architecture: i386
Non-fat file: orbd is architecture: i386
Non-fat file: pack200 is architecture: i386
Non-fat file: policytool is architecture: i386
Non-fat file: rmic is architecture: i386
Non-fat file: rmid is architecture: i386
Non-fat file: rmiregistry is architecture: i386
Non-fat file: schemagen is architecture: i386
Non-fat file: serialver is architecture: i386
Non-fat file: servertool is architecture: i386
Non-fat file: tnameserv is architecture: i386
Non-fat file: unpack200 is architecture: i386
Non-fat file: wsgen is architecture: i386
Non-fat file: wsimport is architecture: i386
Non-fat file: xjc is architecture: i386
---
But admittedly there is no lib/libjava.dylib in the soylatte directory.
It is instead located in jre/lib/i386.
So the soylatte distribution is obviously not Apple-compatible with
regard to directory structure, if apple needs to have the .dylib at a
fixed location.
Symlinking or hardlinking libjava.dylib into the lib directory doesn't
seem to make any difference though. I just get the same error message as
I got initially.
$ export -n JAVA_HOME
$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
$ java -d64 -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
$ java -d32 -version
Cannot run Java in 32 bit mode. Continuing in 64 bit mode.
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
This may be the intended behaviour... but it certainly was a changed
behaviour... and it first led me to believe that something had gone
wrong while installing (until I tried to unset JAVA_HOME).
Hope this will help anyone else with a similar issue.
...so apparently it tries to execute the soylatte java binary because
when I remove the JAVA_HOME environment variable I get:
Sorry for the initial confusion, this is just part of a plan to have a
more coherent story for $JAVA_HOME on Mac OS X. We have also included
a /usr/libexec/java_home command line tool that will print out the
full path to all detected JVMs that match a set of passed criteria
(-d32, 1.5+, etc). The idea is that you set your $JAVA_HOME as follows:
% JAVA_HOME=`/usr/libexec/java_home`
or in your case:
% JAVA_HOME=`/usr/libexec/java_home -v 1.6+`
Then, your $JAVA_HOME will be whatever was at the top of Java
Preferences when you started your session. This also gives flexibility
to developers who have to deploy their apps as shell scripts without
making them hardcode paths to a specific JDK.
This is really good. I will definitely appreciate this feature.
Other JVMs may also be detected from
~/Library/Java/JavaVirtualMachines/ or
/Library/Java/JavaVirtualMachines/, as long as they contain a
$JAVA_HOME/lib/libjava.dylib, and a $JAVA_HOME/bundle/Info.plist that
describes the JVM and it's capabilities. The supported architectures
are detected out of the libjava.dylib binary.
This sounds like a future possible enhancement for SoyLatte/OpenJDK.
Once again, sorry for the confusion,
No problem. I really appreciate the work that you and the Mac OS X Java
team do, although it seems that you could do with some more resources. (:
(I would have appreciated an Apple release of Java 6 for all supported
Leopard architectures instead of just 1 (x86_64) out of 4 (i386, x86_64,
ppc, ppc64)... it's a pity that we need to resort to external JVMs such
as SoyLatte/OpenJDK, even for early Intel-based macs.)
Regards,
- Erik
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
