JAVA_HOME should be set by default to /usr/lib/jvm/default-java

[Etienne Goyer]

By default, we do not have JAVA_HOME set. This is a bit annoying, as it requires an extra step when deploying and installing Java software that depends on locating the JRE through the JAVA_HOME environment variable, such as the EC2 tools, for example.

I just noticed in Jaunty that we now have a soft link /usr/lib/jvm/default-java that point to the system's default JVM. Would it be possible to set JAVA_HOME in /etc/environment to that softlink? That way, Java application that are manually installed would work out-of-the-box.

[Michael Osipov (michael-o)]

I do agree, this is quite annoying. This is still present in Karmic. This should be easy to fix.

[Matthias Klose (doko)]

see the debian policy. you must not rely on environment variables to run your software/packages. You can do this as a user, but this should not be done for the whole system.

[Witoslaw Koczewski (witekk)]

Thank you for this information. Could you also provide a link to this policy? Or better, the motivation for it?

[Boris Devouge (bdevouge)]

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?

[Etienne Goyer (etienne-goyer-outlands)]

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.

[Aren Cambre (aren)]

Also experiencing this bug. Seems pointless not to set such a basic environment variable.

[Niels Thykier (niels-thykier)]

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-al...

[Maxim Veksler (maxim-vekslers)]

Please see comment https://bugs.launchpad.net/ubuntu/+source/java-common/+bug/45348/comments/16 which is related.

[Sebastian Geiger (lanoxx)]

From the commetns I see that this wont be fixed. So setting to invalid.