Supported Versions

We support multiple versions and distribution of Java (both the JVM runtime ("JRE") and development tools "JDK"). Here's a summary of the versions to be found on DICE:

The default Java version on DICE is shown above but it is subject to change over time (though typically only between semesters). However, differences between distributions are nowadays negligible for most users, and specialist requirements mean it's better for users to specify defaults individually. There are different ways to do this, depending on the way your JVM is invoked.

Checking the default version

The default java binaries are normally specified by the "alternatives" system, defined by linking /usr/bin/<appname> to each of the binaries in a given JDK directory. Note that java (provided by the JRE) and javac/javadoc/etc (provided by the JDK) can therefore be different! Your own environment including the PATH variable can override what's been set by alternatives, however.

You can discover the default version by PATH simply by executing:

$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

$ javac -version
javac 1.8.0_191

You can check if this is the version controlled by alternatives by running:

$ which java
/usr/bin/java

(any other result but /usr/bin/java suggests you have already overridden the machine's default version).

Unfortunately the latter doesn't tell you the distribution of javac, only its version. Fortunately this can be inferred from where it's installed, using with the following, e.g.:

$ which javac | xargs readlink -f
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75.x86_64/bin/javac

Choosing your own default version

There are several ways to override the default version as provided by DICE, for example:

• Set aliases in your bash config, if you're mainly interested in interactive use (this is least likely to affect the behaviour of IDEs, for example).
• Create a symbolic link in your ~/bin/ directory for each of the executables (e.g. java or javac) whose versions you wish to change.
• Prepend the /bin JDK subdirectory to your PATH if you are likely to need frequent access to the full set of JVM tools (e.g. wsgen, javadoc, etc.). This is most likely to affect the operation of other programs such as IDEs.

The JAVA_HOME variable

This is not set by default, but users can add this to their ~/.brc to influence certain pieces of software. It can however be confusing to have this in conflict with the default version by PATH so it's recommended that you only set this when required, or tie them together somehow, e.g.

  within .brc:
export JAVA_HOME="/usr/lib/jvm/java-1.7.0-sun/"
alias java="$JAVA_HOME/jre/bin/java"
alias javac="$JAVA_HOME/bin/javac"
alias javadoc="$JAVA_HOME/bin/javadoc"
[...]

remembering that bash aliases only apply to interactive shells (i.e. this will not apply to scripts you've written, with certain exceptions).

Or, on SL7, if you're using module:

within .brc:
# add Java 11 to your shell; displays a harmless error if it's not available:
module add java/11
[...]

You could hide the error on machines without Java 11 by, for example, appending |& grep -v 'Unable to locate a modulefile' to the module invocation.

If you'd like to set the default only for the duration of a script, you could also do so with $PATH at the top of the script itself:

#!/bin/sh
#My scriptfile.sh
export JAVA_HOME="/usr/lib/jvm/java-1.7.0-sun/"
export PATH="$JAVA_HOME/bin:$PATH"
[...]

or, again, on SL7 using module:

#!/bin/sh
#My scriptfile.sh

# add Java 11 to your shell; display an error if it's not available:
module add java/11
[...]

Choosing a JVM directory

It's recommended that you avoid the precisely-versioned links (e.g. "java-1.7.0-openjdk-1.7.0.55.x86_64") unless you are testing a specific build. Automatic updates will mean that these directories will change regularly. In general, if you want to set a specific distribution or version of Java, you should use the most general link available in /usr/lib/jvm/, e.g.:

• Version 10, any distribution: /usr/lib/jvm/java-10
• Latest Sun/Oracle version: /usr/lib/jvm/java-sun
• OpenJDK, version 1.8: /usr/lib/jvm/openjdk-8 (on Ubuntu systems)

...and so on.

/usr/lib/jvm/java-10-oracle/bin/

  (before...)
$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13) 
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

  (find out what optional version of java is available...)
$ module avail java
java/10.0.2

  (make the newest version of Java your default:)
$ module add java
(you can also specify the version directly, i.e. module add java/10.0.2)

$ java -version
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

echo $JAVA_HOME
/usr/lib/jvm/java-10-oracle-10.0.2/

Java Plugin for Web Browsers

tl;dr: Java Applets are no longer supported on DICE: contact us if you need some workaround or specific solution for your applet.

The Java "applet" plugin for web browsers used to be a standard part of the DICE environment, but the popularity of the applet in the wider web has declined significantly, while the security issues associated with applets have become more apparent. Applet support has been officially deprecated by Oracle, support has been long since removed from all major browsers, and as of August 2018 has been removed from Firefox "ESR" release, as carried on DICE.

If you still require the ability to run Java applets you can make use of the legacy appletviewer provided by an older (<= 1.8.x) Java release, and if this workaround doesn't work for you please contact support who can try to find out if there's some other way to do what you want, but can not guarantee any such code will continue to run on our - or any other - modern environment.

Installing libraries

DICE does not provide an extensive Java package library, though it does carry a few popular packages and dependencies for mainstream software. The wider expectation seems to be that software packages will include their own library files where appropriate. Typically this is done by adding jar files to a library directory, and adding these files individually to your software's CLASSPATH, and advice on managing the Java classpath can be found from reputable sources online.

If you have a specific requirement for a Java library to be provided on all DICE machines you may request this in the usual way.