If you are fairly confident and don’t want to read the whole document the following summary should probably be enough to get java working on your system. Lines 1 and 3 are preformed as root line 2 as a standard user.
apt-get install java-package fakeroot make-jpkg <java-binary-package-name>.bin dpkg -i <created-package-name>.deb
A change in the way Java is licensed by Sun Microsystems means that at the moment at least Java 5 is available as a Debian package. This situation may change in the future but with the recent announcement of the GPL’ing of Java it’s looking less likely. I will continue to maintain this page as it is useful for people running the current stable release of Debian and those people who wish to install a version of Java that isn’t packaged (e.g. anything before 1.5 and currently 6.0).
Step 1 – Get the Sun JVM
You could go with other JVM’s like Blackdown or Kaffe if you want. I am not saying they aren’t worth looking at but if you are serious about developing with Java you basically have no choice but to go with the Sun JVM. They provide it for free (as long as you sign you life away) so you might as well use the best.
You can get the latest Sun JVM from here http://java.sun.com/
Step 2 – Install the Required Builder Package
Installing Java on Debian is not the simplest thing in the world but fortunatly there is a package that will do most of the work for you (assuming it works). That heaven sent package is java-pacakge which can be installed with:
apt-get -u install java-package
Make sure that your repository is fully up to date before installing this package or you might run into problems installing the latest JVM. You also need fakeroot if you don’t have it.
Step 3 – Create the .deb Package File
You have to perform this step as a non-root user so I suggest using your own account. Create a temporary directory and copy the java .bin installer file into it. then run the command:
fakeroot make-jpkg jdk-1_5_0-linux-i586.bin
changing the name of the java .bin package if you need to. You may see a few warnings while the package is being created (and it takes some time to actually create it – about 2 minutes). If you see a message at the end saying the package was created then the warnings are not a problem. The message will probably look something like this:
The Debian package has been created in the current directory. You can install the package as root (e.g. dpkg -i sun-j2sdk1.5_1.5.0+update00_i386.deb).
Step 4 – Install the Java .deb Package
You need to be root to perform this step so switch now. Then execute the following command:
dpkg -i sun-j2sdk1.5_1.5.0+update00_i386.deb
Of course you need to specify the correct package name if yours doesn’t match mine. You can find out what the package name is from looking at the success message.
Step 5 – Check it Works
This should be the simplest step. Just execute the command:
as both root and another user to make sure everything is installed correctly. You should see output not a million miles different to that shown below.
java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
Removing the Java Packages
Should you ever want to remove any of the Java packages you have installed you can do that with a command like this:
apt-get remove sun-j2sdk1.5
which would remove the package installed above. If you can’t remeber what packages you have installed try searching the apt-cache for the word sun e.g.
apt-cache search sun
that should turn up the package but will match quite a lot of others as well.
Running with Multiple JVMs
Typically one JVM is enough for anyone but under some situations you need to have multiple JVMs installed. In this situation it is necessary to use update-alternatives to select the JVM that will be used by default. This is a really simple process requiring only that following two commands.
update-alternatives --config java update-alternatives --config javac
Each command will ask you to pick a version of Java to use from the versions installed on your machine.
Dealing with Packages that Require JAVA_HOME
Unlike a lot of packages many (most) Java packages need to know where the Java VM is installed and they do this through use of an environment variable called JAVA_HOME. You can set this for each package or you can set this globally in “/etc/profile”. Some packages, such as Tomcat, that are started by an init script will need to know where Java is installed in order to start at boot time. Since they don’t run in a shell they don’t read “/etc/profile”.
Step 1 – Create a Virtual Java
This step is not mandatory but it will make life much easier in the long run. All versions of Java you install will be placed in /usr/lib with names like j2sdk1.5-sun. Create a symlink to one of these called java using the following command:
ln -s /usr/lib/j2sdk1.5-sun /usr/lib/java
Keep this link uptodate and pointing at which ever version of Java you want as the default. It would be nice if there was a package to do this. Sigh. Maybe there is – anyone know of one?
Step 2 – Adding the Environment Variable to /etc/profile
Once modified your profile file should have changed from something that looks a little like this
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). <...snip...> export PATH umask 022
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). <...snip...> export PATH JAVA_HOME="/usr/lib/java" export JAVA_HOME umask 022
Step 3 Method 1 – Starting Applications Under KDE
This step is optional and only affects you if you want to start a Java application that requires the JAVA_HOME environment variable under KDE (I suspect this is also relevent for other desktops, such as Gnome, as well but I haven’t checked). KDE doesn’t execute /etc/profile when you log in and as such doesn’t set the JAVA_HOME varible. The best way I have found to run a Java application is therefore to create a little wrapper script such as this:
#!/bin/bash JAVA_HOME="/usr/lib/java" export JAVA_HOME <application-name>
where <application-name> is replaced with the application you want to start. Call this script something like start-<application-name> and place it somewhere useful (on the path maybe).
A reader has pointed out that defining JAVA_HOME in /etc/bash.bashrc might work as that “configuration file” is read when a non-login shell is executed. I haven’t tested this a would be interested in feedback about whether it works.
Step 3 Method 2 – Starting Applications Under KDE
Starting applications under (x|k|g)dm is tricky because they do not read either the /etc/profile or your own .profile file when they log you in. Your environment will only get set up properly when you run a shell and even then the environment will only be shared with child processes.
A fairly simple solution to this problem that will work for all applications is to have .profile set up your environment (everything in .profile must be bourne shell compatible). In .bashrc set up bash specific, non-inheriting stuff (shell functions, aliases, bash options, etc) and in .bash_profile, call .profile and .bashrc.
To hook into the xsession startup, create a file called /etc/X11/Xsession.d/75local-profile that contains (you might need to lower the number on this file to get it to execute earlier on if you find things aren’t getting set correctly – try 40 if this is the case):
# # Source a users .profile, etc # PROFILES="/etc/profile $HOME/.profile /etc/xprofile $HOME/.xprofile" for PROFILE in $PROFILES ; do [ -f "$PROFILE" ] && . "$PROFILE" done
This will load your environment before the desktop is started so the desktop and all child processes will have the environment you want. (.xprofile is included in case you want to set up anything specific to X but not for a console login)
Environment setup has to be bourne shell compatible because the the xsession scripts run under the bourne shell, not your normal user shell which is most likely bash.
If you get the following error message when trying to install netbeans it is probably because you are at a terminal logged in as root but root doesn’t currently have a graphical interface (X) running. Simply use a terminal of the currently local user.
The installer is unable to run in graphical mode. Try running the installer with the -console or -silent flag.