Is 'alternatives' really better for managing JDKs than a Symlink and $PATH?

Question

I've just recently upgraded to Fedora 16 (from fedora 12), and have read/been told that instead of setting up different JDKs by using a simple symlink and setting my $PATH to that symlink, I should be using the alternatives tool.

What I don't understand is how alternatives is better for managing your jdk, when it seems you would have to run: alternatives --config not only for 'java' but also all the supporting tools (javac, javaws, jstack, etc). This seems miserable compared to:

(Assume $PATH=/opt/local/java/current/bin:...)

rm /opt/local/java/current
ln -s /path/to/unpacked/jdkX /opt/local/java/current

So my question is:

Why do I hear alternatives is the proper way to manage java tools in newer versions of Fedora when it seems much more cumbersome to fully switch JDK's? Have I just been told poor information, or am I missing something important about alternatives?

(NOTE: Feel free to be brutal if alternatives is clearly better in some way. I'm aware I'm largely ignorant about the tool)

Manuscript

Now, how does alternatives work? ;-) – Numerical

@pst : I'm guessing you're digging to see if I know alternatives does in fact manage symlinks? If you're familiar with alternatives, and can provide some insight that would be great. – Manuscript

Answer 1

General

If you know you just need to swap out one or two tools (ex: java and javac), alternatives seems like the way to go, as it is the intended way to manage application versions.

However, if you are using multiple development tools that may require a JAVA_HOME or JDK_HOME value set, or if you don't know which of the jdk utilities the tool(s) may call, it seems exporting your jdk path to $JAVA_HOME, and prepending it to $PATH is a simpler way to go. It may not be the "correct" way, but it's quicker to switch between java versions, and more transparent as you know all your jdk utilities will be pointed at the same version.

1. Unzip your new jdk to your normal java location (/opt/local/java/jdk_1.X_XX)

2. Symlink your current jdk

   ln -s /opt/local/java/jdk_1.X_XX current
   

3. In ~/.bash_profile OR ~/.bashrc add

   JAVA_HOME=/opt/local/java/current
   export JAVA_HOME
   JDK_HOME=$JAVA_HOME
   export JDK_HOME
   
   PATH=$JAVA_HOME/bin:$PATH
   export PATH
   

4. Now if you need to switch jdks you can just swap the symlink

   rm /opt/local/java/current
   ln -s /opt/local/java/new_jdk_directory current
   

Ubuntu Specific

It appears that on UBUNTU this problem has been solved with update-java-alternatives which will update all of the alternatives for a given runtime or development kit (JRE/JDK).

Manuscript

Answer 2

Alternative is a great, easy and efficient way of managing jdks. You can switch to required version if you want quickly. If you are finding alternative difficult, I advise you to look at this page, which explains alternatives in an excellent way.

Petulah

Thanks for the link. That page provided some helpful information. I'm still not sure I agree that alternatives makes sense for managing full JDKs for heavy development. For example, if using a popular IDE (aka. Eclipse/IntelliJ/NetBeans), the IDE will make use of several java tools (java/javac/jar/etc..), and generally assume the proper JDK tools are on the path. If I go with alternatives, then all the tools are on my path directly in /usr/bin/, but if I need to switch jdks, I have to run alternatives --config for each tool. Managing a single symlink that's added to PATH seems cleaner – Manuscript

Yes, it's true you need to run that command for several executables, but I think it's worth it as the desired result is just a command away and you are helping yourself to get the answer to the question 'From where exactly the appropriate version is being picked up?' :) – Petulah

I do like that with alternatives you always know you can find what version you're pointing to because it's always what /usr/bin/X -> /etc/alternatives/X -> points to. However, I get the same information with which java or echo $JAVA_HOME. Now if I could do something like alternatives --install -p /path/to/pkg/bin pkgname and it would update a symlink in /usr/bin for every element in /path/to/pkg/bin/, I would be 100% for it. I apologize if I sound argumentative. I'm just having a hard time seeing the benefit. The more commands I have to run, the more mistakes I can make. EDIT: format – Manuscript

Answer 3

The alternatives system lets you use one command to manage symlinks for all of those commands all at once, without needing to add something else to your $PATH. It will also handle changes in the list of things that need to be symlinked (including things that don't involve $PATH; JDKs don't only contain commands) with different versions, since each version registers the things that need to be symlinked.

Josefinejoseito

Ok. It seems I'm clearly missing something about the tool. How would I go about switching fully over to jdk1.6.0_32 (living in /opt/local/java/jdk1.6.0_32) with a single alternatives command from the default java-1.6.0-openjdk? From what I've seen if I run something like: alternatives --insall /usr/bin/java java /opt/local/java/jdk1.6.0_32/bin/java alternatives --config java (and switch to the right #) It only updates the alternative entry for 'java', and I would need to run alternatives --install and --config again for all the parts of the JDK I want to manage. – Manuscript