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). > -- Eclipse uses /etc/eclipse/java_home instead of java-common scripts https://bugs.launchpad.net/bugs/45347 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
