Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Hayne is not the last word...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Hayne is not the last word...
Authored by: raider on Jan 27, '06 09:38:11AM

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"

[ Reply to This | # ]
judge for yourself
Authored by: hayne on Jan 27, '06 12:37:58PM
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.

[ Reply to This | # ]
Hayne is not the last word...
Authored by: Mikey-San on Jan 28, '06 12:50:34PM
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?

[ Reply to This | # ]
Hayne is not the last word...
Authored by: raider on Jan 29, '06 05:07:09PM
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.

[ Reply to This | # ]
revised advice
Authored by: hayne on Jan 30, '06 06:11:13PM
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.

[ Reply to This | # ]