I agree that update-java-alternatives should undertake to use all available mechanisms to establish the user's chosen default version of java gets communicated to loading applications which are simply making standard assumptions about the way this dependency injection gets resolved.
Above someone raises the question 'given a choice of N different JVMs a user may have installed, which one should be chosen?' and I feel the clear answer is 'the default version'. Indeed that's what the definition of a default version is! It's the one you choose when you don't know any better. A default version is ALREADY being chosen for a loading application, it's just out of the user's control, which is unfortunate. I'm not a technical idiot, but even after reading this series of posts, it's unclear to me how I get eclipse to pick up the sun JVM using the .jvm or /etc/jvm files. It's been mentioned that you should 'edit' these files. I can go and find out, no doubt, but I already went looking for that, and found update-java-alternatives was the recommended mechanism. The only problem - it doesn't influence the default version of java as loaded through established java-compliant mechanisms, which would surprise most people. A sun version of java is what Eclipse (and many other systems, such as OxygenXML) requires to work. I've set it as my default, and reloaded eclipse. Still no dice. I feel a mechanism designed to set a globally default version of java can't be prissy about the way java actually works, and assert that debian policies are better, leaving users of mainstream java-based programs in the lurch, caught between two sets of developers who each feel they have a fantastic mechanism, if only the other side would accept their superior reasoning. One of the great advantages of java is its cross-platform availability. That's one of the reasons I can freely migrate to linux from the windows and mac alternatives without losing an important set of well-maintained development tools. The java community, as adopters of cross-platform tools, are heavily on the side of open source, and a change to update-java-alternatives which ensures that unmodified scripts load the user's chosen default will help migrators migrate without needless headaches, allowing their colleagues to snipe from the wings 'you can't even load Eclipse on that OS - go back to windows'. Another unfortunate consequence of the current policy could be that rather than merely checking for Java VM validity (through versioning information), the Eclipse and OxygenXML load scripts get hard coded with mechanisms to seek out a Sun JVM, making it difficult to migrate back to a free JVM as your global setting when it indeed does get stable enough and standard enough to load these applications. -- update-java-alternatives does not change the JAVA_HOME https://bugs.launchpad.net/bugs/45348 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
