Eclipse uses /etc/eclipse/java_home instead of java-common scripts

[R. A. Rivas Diaz]

1. Duplication of code

Eclipse requires an installed Java Runtime and uses its own mechanism to allow the user to define some paths to look for a JAVA_HOME. The same mechanism is defined by java-common. Both mechanisms are so similar that I created a symlink from /etc/eclipse/java_home (defined by eclipse) to /etc/jvm (defined by java-common) and eclipse worked flawlessly.

Eclipse initialization script should avoid duplication and use the global configuration defined by java-common. Keeping an extra $HOME/.eclipserc import for special cases is more than enough, and also java-common also supports predefined JAVA_HOMEs.

2. Duplication of maintenance for the user

When a user wants to use a non-default virtual machine, (like the recently added sun-java5) changing the global configuration does not works for eclipse as the user expects.

[R. A. Rivas Diaz (rivasdiaz)]

The attached patch updates the eclipse launcher to use java-common scripts to locate JAVA_HOME.

The patch can be applied using the command:

sudo patch /usr/bin/eclipse eclipse_launcher_should_use_global_java_conf.patch

After this command is applied, the file /etc/eclipse/java_home is not used anymore, and the java version is controlled according to java-common scripts (currently reading a file similar to /etc/eclipse/java_home named /etc/jvm).

[Joachim Beckers (jbeckers)]

this seems the way to go. after all, /usr/share/java-common/jvm-find.sh does the same thing as the code the patch removes.

plus: there's always the option for users to use eclipse with the -vm argument, if they want to specify a different jvm.

[Ignacio Martin Rodriguez (newwen)]

The patch provided by R. A. Rivas Diaz should be applied because of the reasons put forward: duplication of code and maintenance for the user.

[Jerome Haltom (wasabi)]

Thanks for this. I invented this method for Eclipse, then decided the method was pretty good, and so wrote it in java-common... but never went back and updated Eclipse to use it. I'll clear this up sometime soon.

[Mark Reitblatt (mark-reitblatt)]

Jerry:
 Any chance of this getting done in time for Feisty?

[auspex (auspex)]

I opened bug #125274 about this, and it got marked a duplicate, but I'd beg to differ (slightly).

imo, neither the java-common nor eclipse methods are correct.

We have an "alternatives" system, which should always be configured with the user's preferred VM. Alternatives should be used rather than a hard-coded list (which seems to be poorly supported anyway - I removed java-gcj-compat and it's still in /etc/jvm, and java-6-sun was never written there. Then there's a jvm I'm sure I've never installed).

[Jerome Haltom (wasabi)]

Alternatives are system wide. Alternatives also cannot be applied to
specific applications. Hence the creation of the existing java-common
and eclipse methods.

Given that we live in a world with multiple JVMs, some of which work
better than others for different purposes, when coming up with these
(hacks) I thought that this was the best idea.

Perhaps OpenJDK will eventually address this. Perhaps not.

On Wed, 2007-07-11 at 20:35 +0000, auspex wrote:
> I opened bug #125274 about this, and it got marked a duplicate, but I'd
> beg to differ (slightly).
>
> imo, neither the java-common nor eclipse methods are correct.
>
> We have an "alternatives" system, which should always be configured with
> the user's preferred VM. Alternatives should be used rather than a
> hard-coded list (which seems to be poorly supported anyway - I removed
> java-gcj-compat and it's still in /etc/jvm, and java-6-sun was never
> written there. Then there's a jvm I'm sure I've never installed).
>

[auspex (auspex)]

I'm not asking for an "alternative" to be applied to a specific application, I'm suggesting that Eclipse should take advantage of that system-wide setting. That's quite a difference. In any case, /etc/jvm is ALSO system-wide, so where's the difference? The /etc/jvm file suggests that every VM should register itself there - but that doesn't solve the priority issue. alternatives does.

If you already have JAVA_HOME set, eclipse is going to use that anyway.

I don't understand this reluctance to use a tool specifically designed to solve this sort of problem. For those of us (no doubt the vast majority) using Eclipse on a single-user system, we don't want to be having to set the same values in multiple locations. For those few who have Eclipse installed onto multi-user systems, they are still in a position to recommend a specific VM via alternatives, and individual users can override JAVA_HOME as required.

[Jerome Haltom (wasabi)]

On Thu, 2007-07-12 at 16:41 +0000, auspex wrote:
> I'm not asking for an "alternative" to be applied to a specific
> application, I'm suggesting that Eclipse should take advantage of that
> system-wide setting. That's quite a difference. In any case, /etc/jvm
> is ALSO system-wide, so where's the difference? The /etc/jvm file
> suggests that every VM should register itself there - but that doesn't
> solve the priority issue. alternatives does.

Using /usr as an entry in /etc/jvm, which is present by default, results
in it using the alternatives system. ~/.jvm and ~/.jvm.d are also
available for per-user/per-application settings.

> If you already have JAVA_HOME set, eclipse is going to use that anyway.

Yes, but Debian packages cannot rely on environmental variables being
set. It's in policy. Also, in my opinion, it's obnoxious.

>
> I don't understand this reluctance to use a tool specifically designed
> to solve this sort of problem. For those of us (no doubt the vast
> majority) using Eclipse on a single-user system, we don't want to be
> having to set the same values in multiple locations. For those few who
> have Eclipse installed onto multi-user systems, they are still in a
> position to recommend a specific VM via alternatives, and individual
> users can override JAVA_HOME as required.

Uh huh. That's probably why the bug was marked as a duplicate of Eclipse
using it's own system. I wrote the Eclipse system because of a real need
(at the time, anyway) to configure Eclipse and Eclipse alone to use a
different VM than the system VM. Because it did not work with gcj, but I
didn't want to use Sun's VM for a bunch of other crap on the system that
works fine with gcj. Then sometime later I realized that this system
worked pretty well, and could be applied to any Java app, so I wrote the
java-common version. Yes, Eclipse should use the java-common version.
No, I haven't had time to fix it. Yes, you can submit patches to fix it,
or somebody else can.

As for using alternatives, if alternatives can work per-user and
per-application, it sounds like a wonderful idea. But it can't.

Does this clear up any confusion about why alternatives is not
appropriate? I am certainly open to any arguments claiming that nobody
wants to use different JVM's for different applications anymore, and
that nobody wants per-user settings of this type. If you can rephrase
your bug as a specific argument against that, then fine.

[auspex (auspex)]

If the /usr results in "alternatives" being used, I'm happy with that - it wasn't obvious, because of course that was never present in /etc/eclipse/java_home. I'll remove my manually added link to sun-java-6 and try it.

The second point about Debian packages not being permitted to rely on environment variables is not an issue - I don't believe policy _excludes_ them using environment variables, they just can't rely on them. My point there was that Eclipse will use JAVA_HOME as an override if that's what a user wants.

Finally, somebody _did_ submit a patch (first response to this bug), and it works just fine to do what you want (and if the /usr bit works, what I want too), and you haven't used it.

[R. A. Rivas Diaz (rivasdiaz)]

OK, I filled this bug (and the patch), and also filled other bugs related to Java support. For example:

https://bugs.launchpad.net/ubuntu/+source/java-common/+bug/45348 -> update-java-alternatives does not change the JAVA_HOME

In both cases I've proposed a solution to fix the problem. In this particular case Jerome suggested he would fix it (on comment 4) so I forgot it and expected it to be solved some day. But now it seems that the situation has some how changed.

I'm willing to help on this but I need to know what kind of solution is expected. Trying to sum up all requirements, I get the following:

1. Only one way to configure default Java globally.
2. Support for overriding the default Java for a user.
3. Support for overriding the Java version used for an application globally.
4. Support for overriding the Java version used for an application for a user.
5. Mechanism on (1) should preset JAVA_HOME globally.
6. Mechanism on (2) should preset JAVA_HOME for a user.

I think a combination of /etc/jvm and update-java-alternatives (both schemes working together) is the best way to fix this.
I don't like the idea of some Java programs depending on the JAVA_HOME environment variable, but the web is filled with Java applications that the only think they require to work out of the box is a definition of this variable. So having it predefined and working with the global (or per user) way to configure Java is IMHO the best way to help those Java users.

Do you have other requirements? Do yo want something on this requirements changed?

Jerome: how do you want this working to get a chance to be included?

[Jerome Haltom (wasabi)]

> 1. Only one way to configure default Java globally.
> 2. Support for overriding the default Java for a user.
> 3. Support for overriding the Java version used for an application globally.
> 4. Support for overriding the Java version used for an application for a user.
> 5. Mechanism on (1) should preset JAVA_HOME globally.
> 6. Mechanism on (2) should preset JAVA_HOME for a user.

1. If you point /etc/jvm at /usr and /usr only by default, then by
default update-java-alternatives takes effect. The list of default stuff
in /etc/jvm is old and poorly thought out anyways. I guess my hope with
this file was to make it point to only two things: gcj and Sun. Period.
Ask gcj tended to be our "official" "good-enough" Java implementation
(it was most likely to work given all our choices). Sun's would not be
used unless the user changed the order. (Sun's is non-free, and we
cannot rely on it being installed, ever, except for other non-free
stuff. It is better to pretend it does not exist. (OpenJDK??))

2. ~/.jvm already exists.

3. /etc/jvm.d

4. ~/.jvm.d

5. Well, not sure how you're going to manage this. You'll need it as
part of the login path. So, what, take the first entry out of /etc/jvm
and set it in /etc/environment, using some script? Since /etc/jvm
doesn't require a script to be used to alter it, that's not going to
work. Guess writing that code in /etc/profile to set it up might work.
Not sure how you're going to edit that file in any suitable automated
way. Also this file isn't even used by the Gnome or KDE login sessions
is it? Yeah, I think I found the only reliable way to properly set an
environmental variable at login was /etc/environment, as it's done by
PAM.

6. Same problems exist.

To conclude, I think everything except (5) and (6) work now, with the
exceptions that a) Eclipse is broken and b) /etc/jvm is stale. I think
(5) and (6) are going to be hard to accomplish. I've hit this same issue
and arrived at the conclusion that at least for now, making the user set
JAVA_HOME manually has been the best (only) possibility.

[Pander (pander)]

I run this command:

$ sudo ./update-java-alternatives -s java-6-sun

but had to do this manually:

$ sudo vi /etc/jvm (and add the following line to the top of the list)
/usr/lib/jvm/java-6-sun

$ sudo vi /ect/eclipse/java_home (and add the following line to the top of the list)
/usr/lib/jvm/java-6-sun

Please make sure that update-java-alternatives takes care of this (and that installing eclipse after running update-java-alternatives also uses the correct values in /etc/eclipse/java_home).

[Matteo Settenvini (tchernobog)]

Still here, any news on this?

[Pander (pander)]

Situation on Hardy Heron is not much better. After standard installation, one has to install:
1) eclipse
2) sun-java6 (and friends)
But this lead to a configuration on your system that is polluted with gij and gic settings.

One has to manually set:
a) alternatives to sun-java6
b) edit eclipse configuration to use sun-java6
c) edit openoffice configuration to use sun-java6, because it cannot find JRE of sun-java6

Then, still gij, gic and friends are disrupting the party. Deinstalling with dpkg -P of gij, gic and depending friends will sort that out (check that /etc/java is gone and only /etc/java-6-sun is there).

Now your system is properly configured to use sun-java6 automatically in all places.

All this should be managed from one central point and the system admin should be asked which JRE to use each time a JRE is being installed or uninstalled via package manager, subsequently leading to correct configurations as is described above in the case of sun-java6.

[Maha (almaha-1980)]

i am a newbie
can you tell me how to save a patch?
where to save a patch?

the usr/bin/eclipse is not a folder, and even it is, its locked, i can't save anything on it!

i couldn't run the command

sudo patch eclipse_launcher_should_use_global_java_conf.patch

it says:
sudo: patch: command not found !!

[Pander (pander)]

Can this please be fixed in Interpid Ibex? The bug is growing a bit of a beard and such a basic thing should be taken care of very well.

For beginner and intermediate programmers it is demotivating when having to double check several different configuration settings and installed packages before Eclipse is working with th e correct JVM. And even then the question is what will happen when another JVM is installed via apt-get. Will the settings be altered in an unambiguous and easily predictable way?

[George Pollard (porges)]

If "/usr/" always works for update-alternatives surely the simplest fix is to truncate /etc/jvm and /etc/eclipse/java_home to just the line "/usr" (or /usr/lib/jvm/default-java)?

[Daniel Serodio (dserodio)]

Why hasn't this patch been committed yet?

[Niels Thykier (niels-thykier)]

> Why hasn't this patch been committed yet?

I can name two possible reasons:
 * The patch is against an installed system rather than the build system
 * It is more "correct" to fix 36534 [1] if possible.

We will try to fix 36534 [1] in 3.5.0-1 and there by closing this. If fixing 36534 turns out to give more problems, we will implement this one instead.

~Niels

[1] https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/36534

[Niels Thykier (niels-thykier)]

The current eclipse no longer uses this method to determine which JVM to use, see LP #36534.

~Niels