Hi

First of, the policy Matthias Klose refers to is the Debian Policy[1] (see paragraph 9.9). 

Boris Devouge wrote:
> But this is Java ... not really directly relating to debian packages policies, no?
> Majority of java apps (read enterprise software) require it to be set, and it will be nice that something
> like update-alternatives or some other mechanism takes care of it, or is this totally out of scope?

Java itself makes no requirements for any given environment variable to be set. Personally I would recommend that you ask these enterprise software vendors to try the java in PATH if any (be it before or after it checked JAVA_HOME). Eclipse can do this; in fact, eclipse is capable of finding the home of java even when it has to do it by going through a symlink.
  Alternatively convince Debian/Ubuntu to package them if they are open source applications.

Also update-java-alternatives is generally not capable of doing this (see https://bugs.launchpad.net/bugs/45348)

Etienne Goyer wrote:
> What Boris said, plus I do not understand the motivation behind the policy either. More importantly:
> what drawback would there be in setting a global JAVA_HOME?
> 
> And even assuming the policy is actually sound, wouldn't it make sense to break it, if that improve the
>  out-of-the-box user experience? On one hand, we provide a mechanism to point to a default JRE, on
>  the other we purposefully force the user to tweak its environment to make use of it. That is not very
>  coherent.

The motivation behind the policy is to require that commands installed via Debian and Ubuntu's repositories work out of the box. If this policy was not there; you might have to run programs like:

  $ JAVA_HOME=/usr/lib/jvm/default-java JRE_ARGS=-server CACHE=/tmp/app-cache/ application

And no - there is no magical value that will fit all cases, so we would not be able to add these variables in /etc/environment or the profile for your shell. It would be a hell beyond comparison to make this work when two different applications use the same variable but expects different values.
  This is part of the rationale behind the paragraph of the policy. And while this policy only applies to programs packed by Debian or/and Ubuntu, it will not help your case. Simply because there is more than one JVM in Debian/Ubuntu and therefore there is no "perfect" value for all cases[2]. Any tool to update or automate this shipped/created by Debian or Ubuntu would have to comply the policy.

You could try to get "default-java" to be that "perfect" value, except it will never point to sun-java6 and that is what some people use. And some may not have default-java - it is perfectly possible and valid to install the gcc-JVM or even openjdk-6 without having the default-java symlink. Even if we did it, then some would complain that is updated to fit their favorite JVM. In fact, you could argue that they already did (see https://bugs.launchpad.net/bugs/45348).

Finally, some applications in Debian/Ubuntu respects JAVA_HOME if it is set[3]. If we always set, then we would get complains about applications not using the JVM people set as their java alternative. As I explained in #45348, update-java-alternatives cannot update JAVA_HOME, so we would be unable to solve it sanely (the application cannot tell the difference between a user set environment variable and an "default" environment variable). For people using sun-java6 as their java alternative, this will be particularly intrusive change.

~Niels

[1] http://www.debian.org/doc/debian-policy/

[2] Actually in Debian we have a handful of architectures only supporting the gcc based JVM; but this is far from the best JVM available on all other architectures.

[3] This allows user to override the system java; particularly useful for multi-user systems.