Mac System Library Frameworks Javavm.framework

admin 10.04.2020

System/library/frameworks/javavm.framework/versions/current/commands/java
Macos Javavm.framework
System Library Mac
Mac System Library Frameworks Javavm.framework Login
Mac System Library Frameworks Javavm.framework Free

Easily switch the current default Java version 22 comments Create New Account

Click here to return to the 'Easily switch the current default Java version' hint

The following comments are owned by whoever posted them. This site is not responsible for what they say.

To repeat my comment from the last time a 'hint' appeared suggesting a script for changing the Java version by modifying the symbolic links:

Arrgh! Changing the symbolic links (as is done by this script) is the wrong way to do this. This has been strongly recommended against by Apple. The right way to switch between Java versions is to use the facilities provided in the 'Java Preferences' utility (provided with the Java 5 release in a recent software update) for GUI apps, and to change the execution PATH for command-line Java apps.

Since Java 1.5 will very soon (after an imminent Apple update) become the default Java version on OS X, the developers obviously need to fix it to work under Java 1.5 as soon as possible - or at least to ensure that it will use its preferred Java version even if the default is 1.5. How$to$Install$Hadoop?$(On$Mac$OS,$Linux$or$Cygwin$on$Windows)$ $ 1) Download.hadoop.0.20.0.from http://hadoop.apache.org/mapreduce/releases.html.

This was all explained in my macosxhints forums writeup and in this recent hint.

Changing the symbolic links is definitely the wrong way to go.
------------------------

Note that the forums writeup referred to above supplies Bash functions for changing the Java version the correct way - by changing the PATH and JAVA_HOME environment variables.

I also note that Apple is on the verge of releasing a new Java update that will make Java 1.5 (aka Java 5) the default Java version.

Arrgh! Changing the symbolic links (as is done by this script) is the wrong way to do this.

Why? Have you actually tried it? I've been using the symbolic link approach since the 1.5 release was first available, and I've never had any problems. If there ever are problems, though, I can always switch the symbolic link back. It's really not a big deal.

This has been strongly recommended against by Apple.

Link please?

I've been using the symbolic link approach since the 1.5 release was first available, and I've never had any problems. If there ever are problems, though, I can always switch the symbolic link back. It's really not a big deal

I'm not claiming that changing the symlinks doesn't work. Of course it works.
I'm just saying that you shouldn't do it because there is a better way. The better way is to change the PATH and JAVA_HOME variables to point to the version you want. This is better because it is far less intrusive and more flexible. And it doesn't mess with something that is going to get overwritten with the next update from Apple. It's the right thing to do.

Link please?

Apple's release notes say that you should use the full path to the Java executables to specify which version you want.

And here's a Java-Dev mailing list post from an Apple employee that spells out 'the reasons that we recommend developers NOT modify this symlink'.

System/library/frameworks/javavm.framework/versions/current/commands/java

Changing the symlink is not the best way to address this problem, but sometimes it is the most expedient from a risk/reward ratio perspective. I'll give you an example..
When using the Mac OS X distribution of the Zimbra collaboration suite, the JAVA_HOME environment variable is supposed to be set correctly. The only small problem is that it's not. I wasted *hours* trying to figure out why Zimbra wouldn't work, only to realize that it was the fact that Zimbra wouldn't look at anything other than the 1.4.2 JDK. A quick symlink change later, and voila -- everything works like a charm.
Should Zimbra fix the distribution so we don't have to change the symlink? Absolutely. Is there anything wrong with me wanting to get the damn thing up and running without wasting any more time? Absolutely not. If you need to change the symlink in order to make your life easier, but all means -- do it. As others have pointed out ad nauseum, you can always change it back.

Zimbra wouldn't look at anything other than the 1.4.2 JDK. A quick symlink change later, and voila -- everything works like a charm. Should Zimbra fix the distribution so we don't have to change the symlink? Absolutely. Is there anything wrong with me wanting to get the damn thing up and running without wasting any more time?

You didn't make it clear what you were trying to do, or what the real problem was. You said that Zimbra 'wouldn't look at anything other than the 1.4.2 JDK'. But that is (currently) the default JDK, so I don't understand the problem.

But in any case, there is obviously nothing wrong with changing the symlink as a hack to work around some broken software that you need to work now as long as you realize that it is a hack and that you are doing it in desperation. It is quite different to recommend (like the article) changing the symlink as the general way to do things when a much better way exists.

You didn't make it clear what you were trying to do, or what the real problem was.

Actually, I did make it clear. You just didn't get it. Zimbra will not work with a JDK less than 1.5.

You said that Zimbra 'wouldn't look at anything other than the 1.4.2 JDK'. But that is (currently) the default JDK, so I don't understand the problem.

When using the 'much better way' you recommend to specify 1.5 as the default JDK, Zimbra still looks at the 1.4.2 JDK and refuses to run. That is the problem.
The rest of your comment is redundant. Nobody is arguing that changing the symlink is the best way to do things, but rather that it is sometimes a necessary evil.

Zimbra needs JAVA 1.5
it won't work with JAVA 1.4.x (at least on OsX).
I do use the symlink 'trick' to point current JDK to the 1.5;
It works like a charm.
It may be not the BEST WAY (it's the ugly way as I call it) but it works, and it's the ONLY WAY to get zimbra works.
Well it's the only way to get the Zimbra server to work.
The client don't need to change anything. just need to use Firefox as safari dosen't work at all with zimbra.
I've tried many tricks like editing the .profile or .bashprofile etc…
the only way to get things working is to change the symlink to point to 1.5.
---
I luv mac, Vindoze Sucks

Macos Javavm.framework

Agreed, this method can lead to problems..
Cyberduck broke doing this, and the author seems to have had many users complaining of the same thing.
Will

It just allows quickly switching. Something the neat little app from apple claims to do, yet would never do for me.
Anyone can verify by first using the apple application and java -version at the command line. The version is always 1.5 At least that was my experience.
Then follow along with the hint, in this case I named the file 'javaswitch'. Then check results of java -version as you easily switch between java versions, just like the apple utitlity should do, but does not.
pb3:/usr/sbin smokethedog$ java -version
java version '1.5.0_07'
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
pb3:/usr/sbin smokethedog$ sh javaswitch 1.4.2
Current JDK version: 1.5
You must now enter your Mac OS X password to change the JDK.
CurrentJDK -> 1.4.2
pb3:/usr/sbin smokethedog$ java -version
java version '1.4.2_12'
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-269)
Java HotSpot(TM) Client VM (build 1.4.2-76, mixed mode)
It is a switch, like a light switch. Flipping it down does not burn out or break the light bulb. You just have to flip it back up when you want the light to be on!

If it's just a command line problem, why don't you make an alias? For example in zsh

 alias javac15='/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Command$ alias java15='/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands$

I just wish this thing would die.
Hayne seems to think that his word gospel and that we should all believe him because he wrote a forum post.
The WHOLE REASON THAT THEY ARE SYMBOLIC LINKS is so that you can change them. That is the purpose for using symbolic links.. AND - you can ALWAYS change them BACK!
I am a Java developer. I have been using Java 1.5.x with OSX since the first day it was released in beta. I have been using it with modified symlinks since day one.
I use Eclipse, XCode, and several other database and development tools. In addition, I have several Java applications not related to development. Even the most important Java application on my system, Puzzle Pirates. :)
They all work just fine. My system has even been through at least one automated Java update since the beta - which worked just fine and had no problems with the symlinks.
There is no reason to panic and if you would like to try it, changing you symlinks is just fine. If you find it causes a problem for something you use - then change it back. It is that simple.
And would the naysayers please just stop reading the hints regarding changing your Java symlinks - because obviously some people WANT it regardless of what you say. Be happy that you authored a forum post, and that you have warned appropriately and let the rest of us get on with our hints and tips.
As with any of the MacOSXHints - they are *always* 'use at your own risk'

Hayne seems to think that his word gospel and that we should all believe him because he wrote a forum post

No - I think that once you read what I wrote and think about it a bit, that you will realize that changing the environment variables is the better way. As I said above in response to someone else, it's not that modifying the symbolic links doesn't work. Of course it works. But there is a better way, a way that gives you everything that modifying the symlinks does, yet provides the possibility of having per-user or even per-window versioning if you want it. And this way is the way recommended by Apple.

Hayne seems to think that his word gospel and that we should all believe him because he wrote a forum post
No, he listens to developers. The science is valid here.
Did you bother reading the links he posted before getting snotty all over the comments section?

Yes. I have read every one of his links.
I still contend that there is no need to spread FUD (Fear, Uncertainty, and Doubt) about this. Either change you symlinks or don't.
Both methodologies have their implications, impacts, and uncertainty. For me, the certainty that it will work with every application 100% of the time is way more worthwhile than the minimal risk, and greatly added time intensive processes.
Changing the symlink works for all applications, and with only one change. Using the other methods works only sporadically. Some applications ignore the setting in the .plist file, others ignore the JAVA_HOME, and some you can't use an absolute path to Java.exe.
The risk? According to the post on the Apple list: here is the risk:

1) It affect the whole of the system. It other words it may break other applications or Apple's own application / java subsystem which may make assumption about how it is configured. Why use a shotgun when you don't have to?

I *want* it to affect the whole system. I *want* to use the shotgun. I don't want to change 300 settings, plist files, shortcuts, or terminal settings - every time a Java version changes.
Additionally (and maybe on a tangent here) - Maybe Apple should not make 'assumptions' about how things are configured. Didn't this bite them with an iTunes update a while back? There are a billion people in the world - we all like to configure things differently. Apple should not make any 'assumptions'. Ironically, Apple making 'Assumptions' about how things are configured is condemned by #3 in a way..

2) It changes a symbolic link that is managed by Apple (under / System). It may cause updates to break or install incorrectly and/ or an update may change it on you with out you realizing it.

Many things change stuff in /System. Of course you should be aware that upates can break that. How many times has an Apple update broken Apache setups, or PHP, or SSH or other things like that? Lots. It goes with the territory that when you run an Apple update you should check all of your custom configuration items to see if they are broke.

3) It puts your system in a non-standard configuration (differs from what your customers have). Your testing may not find issues that your customer may hit as a result.

It depends. Not everyone is developing, or developing for customers. Some people are just power users who want to get the most efficient JVM in use..
And who says that what I develop has to run against the Apple Java 1.5 JVM? I develop web systems using Eclipse and other tools, and they target Java 1.4.2. I deploy to WebSphere, Oracle 4J, Tomcat, WebLogic, and other servers. I have no problems doing that, while using Java 1.5 on *my* system. My system uses Java 1.5 which Eclipse and other tools run in, and then when I fire up Tomcat or OC4J they use Java 1.4.x, and when I deploy to my test servers they use whatever is on them (which can vary by app server, for example IBM supplies it's own JVM for WebSphere while Tomcat uses the system default).
My applications I support currently range from Java 1.3.x to 1.5.x - and none of them are impacted by my using Java 1.5 on *my* machine.
Why does a 'developer' on an Apple box *have* to be developing applications that run on an Apple box? Or developing user interactive apps of any kind for an Apple box? What if all my customers use Linux? What should I do then? How does Apple's symlink policy deal with that? How does how I configure my JVM on my laptop affect my users on Windows? These are all things that people seem to take for granted. That we are all simply devloping OSX applications and that OSX is the only thing that we use daily. Nope. Some of us develop for and use many different OSs in many different configurations.
Again, I say only that YOUR MILEAGE MAY VARY.
But please don't just shout - DON'T DO THAT! or THAT IS WRONG! - because that is not true. What is true is that there are different ways to do things, and all of them have their plusses and minuses. It just gets old having to defend a proven methodology over and over.
What would be better is to say:
'You can do it this way, and here is another way that you can do it - which is different because..'
Which Hayne has seemed to have done when people take him to task. But initially he is very inflamitory and resorts to scare tactics. People need to know that Hayne's word is no more gospel than mine. This is just *information* for people to use while making decisions..
As with anything on MacOSXHints - changing things has potential to do harm. If you want a 100% stock configuration as supplied by Apple, you should pretty much ingnore MacOSXHints.

Okay here's a revised 'headline':

'Do not do this! (unless you are desperate, or don't want to bother finding out the Apple-sanctioned way, or you have unusual needs and the recommended way doesn't work for you)

In other words, my vociferous objections have always been to the promotion of changing of the symbolic links as a good way to switch Java versions. It's a way, but one that should only be used as a last resort, or if you have unusual needs and you understand all the ramifications.

System Library Mac

I'd like to point out that Sun (who invented Java) does precisely the same thing in Solaris to allow the sysadmin to change which java the user gets by default. Which is why /usr/bin/java is a link and not a real binary.
UNIX systems often use links to allow multiple version support, and OS X is no different.

Re: Easily switch the current default Java version

'Mac OS X is no different'..*except* it supplies a *better* way to do this than use the brute-force UNIX method, and the Apple-sanctioned way, as an added benefit, *will not break* Java apps which expect the symlink to be pointed correctly. This is what hayne has been saying for months and what the Apple Java-dev posted linked above stresses.
I do user support and bug report triage for a modestly popular Mac OS X Java app that has only been qualified on Java 1.4.2, and no matter what methods the developers use to keep the app from loading Java 1.5, people (and other Java 'developers') blithely mucking with the symlink continue to generate bogus bug reports of crashes, strange behaviors, and other bizarre problems that, after much time spent troubleshooting and tracking down the problem, turn out to be red herrings; the problems always end up being caused by improper mucking with the symlink.
This mucking wastes everyone's time, breaks Apple-supported methods of ensuring Java apps use the JVM the author intends, causes unnecessary problems, and is something which should not be spread around any further. Please, stop spreading this maddness! (hayne, you have our heart-felt appreciation for your role in trying to nip this insanity in the bud from day one!)

I do user support and bug report triage for a modestly popular Mac OS X Java app that has only been qualified on Java 1.4.2, and no matter what methods the developers use to keep the app from loading Java 1.5 ..

But in the meantime, you might consider having the app check what Java version it is running under (using the method of the 'JavaVersionDialog' class supplied in the forum post referred to above) and simply quit if it detects a version that it can't support.

Re: Easily switch the current default Java version

One of the problems with many Java applications and/or the developers of them - is that they treat Java like a compiled language where you can guarantee more about how your application is run..
Which could be a problem with Java itself. It could probably be argued both ways.
But when you develop a Java application that is going to be run in unknown environments - you HAVE to account for EVERY POSSIBLE configuration. You HAVE to - or you get the problems you describe.
Hell, dealing with classloader issues in different custom JVMs is a pain in the arse. IBM is constantly mucking with the classloading in the JVMs they ship with WebSphere - and BEA likes to break standardized things like SSL.. And don't even try and get into having cross JVM compatible encryption and the like without accounting for almost every possible difference in environment..
Even in my work - where I can reasonably guarantee the environment of a server, I regularly run into a problems when porting to other systems with similarly 'stable' environments.
Like an old instructor of mine was fond of saying - 'if you write it so it will run everywhere it will run nowhere.' :)
We go to production with the Java we have - not the Java we want..
:)

Easily? - I guess using the Java Preferences Utility (which is also the official method recommended by Apple) is much easier..

The hint is about switching the Java version for command-line apps. As is explained in the previous hint and forum writeup I refer to in my first comment (above), the Java Preferences pane does not affect apps that are started from the command-line (in Terminal).
Most people don't have to deal with command-line apps, but if you do, the right way to do it is explained in the forum writeup referred to above.

'Easily? - I guess using the Java Preferences Utility (which is also the official method recommended by Apple) is much easier..'
NO, this won't change anything, at least when we talk about zimbra.
---
I luv mac, Vindoze Sucks

This section explains how to install Project WebSynergy software witheither GlassFish v3 or GlassFish v2 Application Server software. Note that these instructionsinclude some additional steps you need to perform when installing WebSynergy onsystems running Mac OS X.