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.
...so apparently it tries to execute the soylatte java binary
because when I remove the JAVA_HOME environment variable I get:
$ 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.
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.
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.
Once again, sorry for the confusion,
Mike Swingler
Java Runtime Engineer
Apple Inc.
_______________________________________________
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
