Notes on Java

Short Version

Because Red Hat didn’t use to provide Sun Java, we would install and maintain it by hand, necessitating a page documenting where java was installed and how to include it in your path, but now that (as of mid-2007) Red Hat provides Sun Java, this system is deprecated.

/usr/bin/java{,c,etc} should point to the latest installed version of Sun Java tools on all public RHEL systems (which as of November 2008 is Java 1.6). /usr/bin/ should be in everyone’s default PATH, so you shouldn’t need to do anything special, just type java or javac (etc) to get the program you want.

If you want an older version of java, look in /etc/alternatives, which contains symlinks to various versions of software. To use java 1.5, for example, simply run /etc/alternatives/java_sdk_1.5.0/bin/java

Note that all of this information applies only to the Linux machines. On the Macs, java is installed with the Developer Tools package into /usr/bin/java and maintained by Apple. As of November 2008, Apple Java is still on version 1.5.

For historical reasons, the old java notes page is archived here. If you implemented any of the scripts that the old page suggested for our old setup, you can safely remove them, but they shouldn’t cause any harm if you leave them in place.

Long Version

These notes pertain to the use of Sun Java on machines running Red Hat Enterprise Linux:

Until approximately mid-2007, the license under which Sun Microsystems released their implementation(s) of Java was not considered compatible with redistribution by Red Hat, Inc, the vendor responsible not only for the core OS we run on our linux machines, but also for the vast majority of installed software on those machines.

As such, we (CS Systems Operations) would manually install and maintain working copies of Sun Java on all managed machines. Red Hat’s packaged version of the GNU Compiler for Java (GCJ) was accessible at /usr/bin/java, and our local installs of Sun Java were maintained under /usr/java.

Following Sun’s relicensing of (almost all of) Java, Red Hat now packages and distributes Sun’s Java, and all managed workstations installed during or after summer 2008 should have Red Hat packaged copies of Sun Java accessible via /usr/bin/java (maintained as a series of symlinks with the alternatives(8) system). Manually installed copies of Sun Java are now deprecated, and are being removed and replaced where they still exist.

To see which java command your shell invokes when you run java (you can always specify the full path to an alternate install if you don’t want to change your PATH or only need to make one-time use of an alternate java), run which java.

To see what version of java any given instance is, run java -version. Some examples of how different java versions appear:

Sun packaged (Manually installed) Sun Java:

$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)

Red Hat packaged GCJ:

$ java -version
java version "1.4.2"
gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-10)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Red Hat packaged Sun Java:

$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

As you can see, the differences in output between Sun packaged Sun Java and Red Hat packaged Sun Java are minimal, as they are both distributions of the same code. The reason for this change in how we install and maintain java is threefold:

• Our convenience:
  Installing and maintaining software from Red Hat’s package trees as opposed to third party sources is easier for us by several orders of magnitude, especially when we need to maintain the same software on an arbitrary number of machines across the department (which we can do through Red Hat’s enterprise-grade management tools).
• Your convenience:
  By shifting to a java that we can more easily install and maintain, the odds that you will be using a compiler that is out of date, improperly installed, or not up to date on the latest bug fixes and enhancements is greatly reduced, enabling you be more confident that you are developing with the most up to date tools available.
• Standardization:
  By shifting to maintaining java through the alternatives(8) system, no one need contend with home grown “standards” and install locations outside of the Filesystem Hierarchy Standard. No longer need you worry about updating your PATH to switch to a new point release, or remember whether it’s j2sdk or jre to jdk, or contend with paths like /usr/java/java1.5/bin/java or /usr/java/jdk1.6.0_07/bin/java. If you want java, /usr/bin/java should now be the only command you need to run on all up to date workstations to get the latest Sun Java compiler.

If you have need for an older java, a specific point release, or some piece of information not listed above, please do not hesitate to contact guru for assistance.

Last modified: September 6, 2007

guru@cs.brandeis.edu