I've just installed the sun jdk for a course I was doing. When the installation had finished, I set about checking it out, and noticed that each of the component tools (java, javac..) exists as symbolic link in /usr/bin, whose target is a symbolic link in /etc/alternatives, whose target is the tool itself.

This seems overly complicated to me. Is there an advantage in doing it this way? I am tempted to link from /usr/bin/<tool> straight to the appropriate file in the java folder in /usr/lib.

Yours,
Rob

Hi Rob,

Which version of Ubuntu are you using?

If it's dapper (6.06) or above, then you are better off installing the precompiled ubuntu packages. I would recommend that you remove the JDK which you have installed and then install the ubuntu ones with:

You will just need to accept the license during installation and that's it, you're up and running.

On the other hand you can continue to maintain your existing version, but I can't guarantee you will be able to get it to work easily. The /etc/alternatives dir is a more organized way of handling symlinks for multiple versions of one program (Sun Java, GCJ, Blackdown Java...) and linking /usr/bin/java* to appropriate binaries may cause problems with programs that depend on it (don't know of any programs at this time).

You can try the "update-alternatives" script but with parameters that point to your JDK installation.

There is of course, the fully detailed JAVA Howto for DEbian Ubuntu available here

Hope that helps.
--LM

Thanks for the reply.

Actually, I installed via Synaptic from the repository, so it is the "official" Ubuntu version. Some of the symlinks were created/changed to point to the Sun tools (e.g. javac), while others were left pointing to the gcj ones.

After changing the link targets, java is generally working, but I'm having another (little) problem, in that sound isn't. A program which uses sound throws the following error:

line unavailable javax.sound.sampled.LineUnavailableException: Audio Device Unavailable

Edited to add: Actually, I've just solved that, though I don't really understand why I was getting the error. The solution was to change the ownership of the jar containing the sound file to my user account (from root). However, it had read and execute permissions set already, so should have worked, I would have thought.

Yours,
Rob