Why doesn't the Java SDK installer set JAVA_HOME?

Question

I always wondered why I have to manually set the JAVA_HOME environment variable after installing the Java SDK.

JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12

Visual Studio at least provides a batch file to set these kind of environment variables:

call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"

Does Java have something similar? I'm trying to make a build script that should simply work after installing the Java SDK. I don't want people to mess with environment variables on their PC.

Answer 1

You can install as many versions of Java as you like.

It would be dangerous for the setup to modify a local environment variable such as JAVA_HOME, since it might reference an existing Java installation.

This has nothing to do with an alleged "platform dependent issue". ;)

Since scripts might depend on JAVA_HOME to launch themselves, again, this would be disasterous for a new Java install to modify JAVA_HOME: all those scripts would suddenly have to be launched with a new potentially incompatible JVM.

Plus, by setting $JAVA_HOME/bin or %JAVA_HOME%/bin in your path, you can dynamically change JAVA_HOME to whatever version of Java you want to use without having to much with your PATH variable.

---

Michael Borgwardt has made in the comments the interesting followup's question

Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.

The answer is simple:

The setup cannot know if a script already depends on JAVA_HOME or not.

Meaning: some scripts could test for JAVA_HOME value, and if not set, refer to another JVM installed elsewhere (and do not forget that by "install", one can only refer to "copied": a JDK/JRE is not always installed by a setup)

If you set JAVA_HOME, that can disrupt the default behavior of some of your scripts.

Not wanting to disturb hypothetical scripts that depend on a env var not being set sound pointlessly paranoid to me - If a script does that, then it clearly WANTS to use a different JVM when one is installed - no reason to avoid that.

Mmm... Sweet. For dealing with massive deployment issues on a daily-basis (for internal application in my shop), I can assure you: it is very sane "paranoid" treat to have.
When you deploy to a (very) large set of users, you do not want to make any assumption about their platform and configurations. "clearly WANTS" is an assumption I would not dare to make (or I redirect my phone to yours ;) and you handle the angry calls).

For instance, we have many scripts which launches with a 1.4.2 JVM from sun (JAVA_HOME not set on development platform, default path set directly in the script), or with 1.4.2 from JRockit (JAVA_HOME set, as it is the intended target on integration, pre-production and production platforms).

But we install regularly the new JDK1.6.x since we use it for launching eclipse.

Assume that those scripts want their JAVA_HOME set... and nothing works anymore.

... To which Robert Grant makes this on-the-spot critic:

You're describing scripts that require one specific version, but still look at global JAVA_HOME. That's just badly thought out scripts.

While that may or may not be true, that also illustrates precisely my point:
"you do not want to make any assumption": no assumption on their platform/settings, and no assumption on their "best practices".
The former may sound paranoid, the latter is plain common-sense: thinking that your product (here a JDK setup) will not break anything on the user's environment because the user has "correctly" thought out his scripts... would be insane.

---

GvS suggests:

Or it could just have option to do it, disabled by default

That would mean another option to include in the setup screens, option which should be carefully reviewed by the user, and which may have unintended consequences, even when the user selects it thinking he knows what he is doing...

It is simply not worth it.

Answer 2

I don't think JAVA_HOME is a convention invented or supported by Sun.

They probably remember the fiasco that was the CLASSPATH environment variable** all too well and prefer to stay the hell away from environment variables.

** This was encouraged as the primary way to set the JVM classpath in earlier Java SDKs and literature, and resulted in the user and various applications messing with the environment variable, overwriting each other's changes and depending on mutually contradictive contents.