Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Java version
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java version



On May 27, 2009, at 1:31 PM, David Clunie wrote:

Actually I guess the bug is that

 /System/Library/Frameworks/JavaVM.framework/Home

should link to

 Versions/Current/Home

rather than CurrentJDK ?

No, for very nuanced reasons.

If I look at:

 % ls -l /System/Library/Frameworks/JavaVM.framework
 ... Classes -> Versions/CurrentJDK/Classes
 ... CodeResources -> Versions/A/CodeResources
 ... Commands -> Versions/CurrentJDK/Commands
 ... Frameworks -> Versions/Current/Frameworks
 ... Headers -> Versions/Current/Headers
 ... Home -> Versions/CurrentJDK/Home
 ... JavaVM -> Versions/Current/JavaVM
 ... Libraries -> Versions/CurrentJDK/Libraries
 ... Resources -> Versions/Current/Resources
 ... Versions

there seems to be remarkable variety with respect to whether
CurrentJDK or Current is used.

These are they way they are for very good reasons, including having native applications that link the JavaVM.framework find resources where they expect to, having man pages show up where expected, and my personal favorite, backwards compatibility.


I guess one should just avoid hard-coded references to
/System/Library/Frameworks/JavaVM.framework/Home completely ?

You should avoid hardcoded references into /System. Even /Library/Java/ Home should be avoided. That is what /usr/libexec/java_home is suppose to solve. The fundamental issue is that no one $JAVA_HOME can be all things to all applications, which is why /usr/libexec/java_home will pick the best one for you depending on the requirements you provide it.


That said, should Java Preferences be updating CurrentJDK
as well as Current ?

Java Preferences does not and cannot change any symlinks, because it runs with the same privileges as the currently logged in user. Nobody can or should should be changing symlinks in /System/Library/ Frameworks/JavaVM.framework except for Apple software updates (and we are loath to do so, because it inevitably breaks someone). Java Preferences only changes a per-user, per-machine preference in your home directory, which the /usr/bin, /usr/libexec/java_home, JavaApplicationStub, JavaCocoaPlugin.bundle, Java Web Start.app, etc, etc all pick up on.


Using hard paths on the file system will inevitably lead to fail, as Java changes versions and move around on the file system.

Cheers,
Mike Swingler
Java Runtime Engineer
Apple Inc.

David Clunie wrote:
Hi Mike

I did not think I had JAVA_HOME set, but when I checked, it
was set to "/System/Library/Frameworks/JavaVM.framework/Home"
by my .cshrc, along with ANT_HOME, presumably to compile some
package or other I had forgotten about.

That said:

% ls -l /System/Library/Frameworks/JavaVM.framework/Home
... /System/Library/Frameworks/JavaVM.framework/Home -> Versions/ CurrentJDK/Home


and

% ls -l /System/Library/Frameworks/JavaVM.framework/Versions/ CurrentJDK
... /System/Library/Frameworks/JavaVM.framework/Versions/ CurrentJDK -> 1.5


which presumably is not right, and should be linked to 1.6.

If I turn on JAVA_LAUNCHER_VERBOSE, it reports:

 % java -version
 about to exec: "/System/Library/Frameworks/JavaVM.framework/Home"
 about to exec: "/System/Library/Frameworks/JavaVM.framework/Home"
 java version "1.5.0_19"

If I unset the JAVA_HOME environment variable, it reports:

% % java -version
GetInstalledJVMVersions: ignored version [.] - not a digit
GetInstalledJVMVersions: ignored version [..] - not a digit
GetInstalledJVMVersions: ignored version [1.3] - old
GetInstalledJVMVersions: ignored version [1.3.1] - old
GetInstalledJVMVersions: ignored version [1.4] - old
GetInstalledJVMVersions: ignored version [1.4.1] - old
GetInstalledJVMVersions: found version [1.4.2]
GetInstalledJVMVersions: ignored version [1.5] - old
GetInstalledJVMVersions: found version [1.5.0]
GetInstalledJVMVersions: ignored version [1.6] - old
GetInstalledJVMVersions: found version [1.6.0]
GetInstalledJVMVersions: ignored version [A] - not a digit
GetInstalledJVMVersions: ignored version [Current] - not a digit
GetInstalledJVMVersions: ignored version [CurrentJDK] - not a digit
available JVMs:
1.6.0_13 (x86_64): /System/Library/Frameworks/JavaVM.framework/ Versions/1.6.0/Home
1.5.0_19 (x86_64): /System/Library/Frameworks/JavaVM.framework/ Versions/1.5.0/Home
1.5.0_19 (i386): /System/Library/Frameworks/JavaVM.framework/ Versions/1.5.0/Home
1.4.2_21 (i386): /System/Library/Frameworks/JavaVM.framework/ Versions/1.4.2/Home


obtained version: "1.6.0_13"
set preferred architecture to: "x86_64"
about to exec: "/System/Library/Frameworks/JavaVM.framework/ Versions/1.6.0/Home"
java version "1.6.0_13"


I will either remove the JAVA_HOME for now, or have .cshrc
set it to `/usr/libexec/java_home | tail -1`.

Thanks ... David

Mike Swingler wrote:
On May 27, 2009, at 12:38 PM, David Clunie wrote:

Hi Mike

Using "Java for Mac OS X 10.5 Update 4 Developer Preview", changing
the JRE version in "Java Preferences" application to put "Java SE 6"
at the top of the "Java Applications" list, does seem to change what
is reported by "/usr/libexec/java_home":


/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

but does NOT seem to change the link for "/usr/bin/java":

% /usr/bin/java -version
java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_19-b02-298)
Java HotSpot(TM) Client VM (build 1.5.0_16-135, mixed mode, sharing)
This looks like a bug (or at least it works for me). Do you have the
$JAVA_HOME environment variable set to anything?

% ls -l /usr/bin/java
... /usr/bin/java ->
/System/Library/Frameworks/JavaVM.framework/Versions/Current/ Commands/java



which I thought it should.

Am I missing something here ?
The /usr/bin Java tools symlink into JavaVM.framework/Versions/ Current,
instead of JavaVM.framework/Versions/CurrentJDK, because they point to
shared command line tools that live inside of
JavaVM.framework/Versions/A/Commands. These shared command line tools
should pick the top version of Java available from the Java
Preferences.app. Why yours isn't doing that, I'm not sure.


Since /usr/bin is in the default path for all routine command line
activities, why should one have to or want to do anything java- specific
to work around this ?


I.e., am I looking at a bug, or is this intentional behavior not to
update the "/usr/bin/java" link ?
The /usr/bin/java command line tool should point into
JavaVM.framework/Versions/A/Commands/java, because it will dynamically
re-exec and should pick the highest Java version in the Java Preferences
application priority list.


If it is a bug, what is the "correct" behavior, i.e., what changes
should one make (manually) to emulate what the correct behavior
of Java Preferences is expected to be with respect to /usr/bin/java
(and /usr/bin/javac, etc.), until the next update ?
The correct behavior would be to just run the Java version and
architecture at the top of your application preferences list.

Since JavaVM.framework/Versions/Current links to
JavaVM.framework/Versions/A rather than 1.6 or 1.6.0 or whatever,
it is not obvious what to do here (or why there is this A folder
there in the first place).

If this is not a bug, and the intention is to no longer support
the commands from /usr/bin, why have them there in the first place ?
It is a bug. Also, setting the $JAVA_LAUNCHER_VERBOSE=1 environment
variable should show you the ugly (and sometimes misleading) internal
mechanics of what the switchable command line tool is doing.


Mike Swingler wrote:
Versions/CurrentJDK is an on-disk implementation detail of making things
like man pages and maintaining path-backwards compatibility. It should
not be used if you can help it.


If you try out the new Java for Mac OS X 10.5 Update 4 Developer Preview
available now from ADC:
<https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20363 >,


you should be able to use a new tool "/usr/libexec/java_home" to obtain
the "best" version of $JAVA_HOME for you. We don't explicitly set a
$JAVA_HOME on Mac OS X, because there isn't necessarily a right answer
for all applications.


The most future and backwards compatible thing you can do in a shell
script is:


1. Check for the existence of "/usr/libexec/java_home", and provide it
your version/arch requirements (if any).
2. Failing that, check for the existence of the full
"/System/Library/Frameworks/JavaVM.framework/Versions/1.X/Home directory
you know works.
3. Failing that, fall back to "/Library/Java/Home", and pray for the
best.


Please don't manually fiddle with the symlinks inside of the
JavaVM.framework. There are no user-serviceable parts inside. :-)

Cheers,
Mike Swingler
Java Runtime Engineer
Apple Inc.

On Apr 27, 2009, at 11:23 AM, Hein Meling wrote:

Thanks, that works for ant!

But I'm wondering why
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK points
to 1.5 even though Java Preferences is set to 1.6.


What is the appropriate tool to use to update the CurrentJDK link?

I did some experiments a while back simply doing

rm -f CurrentJDK; ln -s 1.6 CurrentJDK (or something like that)

However, this seemed to screw up something else, because Eclipse
stopped working on me; crashing immediately after startup (cannot
recall the error message).

Any help be appreciated!

All the best,

:) Hein


On Apr 22, 2009, at 15:29 , Anuj Seth wrote:

Hi,

You can try setting JAVA_HOME in your .bash_profile, ant will pick
that up.


For example,

export
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/ 1.6/Home/



gives,

anuj-seths-macbook:~ anujseth$ ant -diagnostics | grep java.vm.version
java.vm.version : 1.6.0_07-b06-57
anuj-seths-macbook:~ anujseth$ ant -diagnostics | grep
sun.boot.library
sun.boot.library.path :
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/ Libraries



hope this helps, anuj.


On Wed, Apr 22, 2009 at 1:56 PM, Hein Meling <email@hidden >
wrote:
Hi all,

I've configured the Java SE 6 at the top for both applet and
application
versions in the Java Preferences, and this gives me:

machine>> which java
/usr/bin/java
machine>> java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
machine>> ls -la /usr/bin/java
lrwxr-xr-x 1 root wheel 74
2008-09-28
21:23 /usr/bin/java ->
/System/Library/Frameworks/JavaVM.framework/Versions/Current/ Commands/java



machine>> javac -version
javac 1.6.0_07
machine>> which javac
/usr/bin/javac
machine>> ls -la /usr/bin/javac
lrwxr-xr-x 1 root wheel 75 2008-09-28 21:23 /usr/bin/javac ->
/System/Library/Frameworks/JavaVM.framework/Versions/Current/ Commands/javac




(as expected).

However, when I run ant it does not use this version of java/ javac:

machine>> ant -diagnostics
------- Ant diagnostics report -------
Apache Ant version 1.7.0 compiled on August 25 2008
ant.java.version: 1.5
java.runtime.name : Java(TM) 2 Runtime Environment, Standard Edition
sun.boot.library.path :
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/ Libraries
java.vm.version : 1.5.0_16-133
java.runtime.version : 1.5.0_16-b06-284


Note that: ...JavaVM-framework/Versions/CurrentJDK points to 1.5.

Can anyone please tell me how to fix this problem in the appropriate
way?


All the best,

:) Hein
_______________________________________________
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


References: 
 >Re: Java version (From: David Clunie <email@hidden>)
 >Re: Java version (From: Mike Swingler <email@hidden>)
 >Re: Java version (From: David Clunie <email@hidden>)
 >Re: Java version (From: David Clunie <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.