- Mac System Library Frameworks Javavm.framework Edition
- Mac /system/library/frameworks/javavm.framework/versions/current
Sep 02, 2009 damorgan wrote: I am trying to use my pet cat as a boat and it doesn't work either. That's because, just like the OP, you are not taking the right approach. You simply need to MODIFY the cat - in your case, by adding a few things: a keel, ribs, hull, mast, sails, rudder, tiller (to name a few).
| Click here to return to the 'Easily switch the current default Java version' hint |
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.
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'.
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
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!
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 postNo - 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.
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?
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.
'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.
Mac System Library Frameworks Javavm.framework Edition
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.
'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 ...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.
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.
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...
:)
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.
To Install WebSynergy Software With GlassFishv3
(Mac OS X systems only) Configure your Javaenvironment.
If using JDK 1.6, use the Java Preferences application to specifythe correct JDK version.
Also be sure to set JAVA_HOME topoint to JDK 1.6.
If using JDK 1.5, rename the 14compatibility.jar file.
The 14compatibility.jar file includes someaspects of the Xalan XSLT processor and the Crimson XML parser that conflictwith newer versions of the classes bundled with WebSynergy Milestone 3.
Use the following commands to rename the 14compatibility.jar file:
Download and unzip the websynergy-gfv3.zip package to the directoryof your choice.
For the remainder of these instructions, the directoryin which you have unzipped the websynergy-gfv3.zip is referred to as ws_install_dir.
Change to the ws_install_dir/glassfish/bin directoryand start the GlassFish application server.
This starts the GlassFish server, bundled database server, and the WebSynergysample site using the default configuration settings.
Note –You may receive the following error when starting the server:
This message can in most cases be ignored, but it may indicate thatthere will be a delay of several minutes before the server is actually available.
(Mac OS X systems only) Configure the domain.xml file 64–bit JVM.
When running any64-bit JVM such as JDK 1.6 (which runs by default in 64-bit mode on Mac OSX), you need to edit the domain.xml file in the GlassFish domain1/config directory.
Stop the GlassFish domain1 server.
Edit the domain.xml file for domain1,changing the PermSize and MaxPermSize propertyvalues.
This domain.xml file is located in ws_install_dir/domains/domain1/config. Change the PermSize and MaxPermSize values as follows:
-XX:PermSize=192M to -XX:PermSize=256M
-XX:MaxPermSize=192M to -XX:MaxPermSize=256M
Restart domain1.
(All operating systems) Open the WebSynergy samplesite.
Point your Web browser to http://localhost:8080.
Note –The page may take a long time to load the first time after serverstart. If you see the default GlassFish “Your site is installed”page or a mostly empty page with a single text link titled “Welcome,”wait a few minutes and then refresh the page. Subsequent page loads shouldproceed more rapidly.
To Install WebSynergy Software With GlassFishv2
Mac /system/library/frameworks/javavm.framework/versions/current
(Mac OS X systems only) Configure your Javaenvironment.
If using JDK 1.6, use the Java Preferences application to specifythe correct JDK version.
Also be sure to set JAVA_HOME topoint to JDK 1.6.
If using JDK 1.5, rename the 14compatibility.jar file.
The 14compatibility.jar file includes someaspects of the Xalan XSLT processor and the Crimson XML parser that conflictwith newer versions of the classes bundled with WebSynergy Milestone 3.
Use the following commands to rename the 14compatibility.jar file:
Download the websynergy-gfv2-platform.zip file for the platformof your choice to the directory of your choice.
For the remainderof these instructions, the directory in which the ZIP file is unpacked isreferred to as ws_install_dir.
(Solaris and Linux systems only) When installationis complete, change to the ws_install_dir directory and make the files inthe ant/bin directory executable.
Run the Ant setup.xml script.
The required GlassFish domain and database configuration proceeds. Whenthe “BUILD SUCCESSFUL” message is displayed,the WebSynergy installation is complete.
Change to the ws_install_dir/glassfish2/bin directoryand start the GlassFish application server.
This starts the GlassFish server, database server, and the WebSynergysample site using the default configuration settings.
Note –You may receive the following error when starting the server:
This message can in most cases be ignored, but it may indicate thatthere will be a delay of several minutes before the server is actually available.
(Mac OS X systems only) Configure the domain.xml file 64–bit JVM.
When running any64-bit JVM such as JDK 1.6 (which runs by default in 64-bit mode on Mac OSX), you need to edit the domain.xml file in the GlassFish domain1/config directory.
Stop the GlassFish domain1 server.
Edit the domain.xml file for domain1,changing the PermSize and MaxPermSize propertyvalues.
This domain.xml file is located in ws_install_dir/domains/domain1/config. Change the PermSize and MaxPermSize values as follows:
-XX:PermSize=192M to -XX:PermSize=256M
-XX:MaxPermSize=192M to -XX:MaxPermSize=256M
Restart domain1.
(All operating systems) Open the WebSynergy samplesite.
Point your Web browser to http://localhost:8080.
Note –The page may take a long time to load the first time after serverstart. If you see the default GlassFish “Your site is installed”page or a mostly empty page with a single text link titled “Welcome,”wait a few minutes and then refresh the page. Subsequent page loads shouldproceed more rapidly.