Configuring the J2SDK

---

Extracting the J2SDK is the easy part; it's somewhat more complicated to get it working correctly. This section will discuss techniques for configuring the J2SDK for actual use. There are two main goals: It should be possible to install multiple versions of the JDK on the system at the same time without conflict, and it should be quick and easy to install and use Java applications.

The /opt/java Directory

In the previous section, the JDK package was installed into /opt/java/sun-jdk-1.4. This is a bit of a deviation from the normal practice of installing software directly into /opt. (For example, in Chapter 11 the Apache HTTP Server was installed directly as a subdirectory of /opt.) The reason for creating an entire separate subdirectory for Java software is because there's more to Java than just the J2SDK. The J2SDK is just the beginning: Once it's installed, actual programs that are written in Java will need to be installed, and Java support libraries also need to be installed.

In this sense, the J2SDK (or any JDK) is really its own little operating system, with programs and libraries that need to be installed on top of it. This would quickly clutter up the /opt directory, so the /opt/java subdirectory was created. It works just like /opt, except that it contains only Java-related files. The /opt/java directory as used by this book contains the following files and directories:

• /opt/java/[directory]: Separate subdirectories for each JDK to be installed

• /opt/java/packages: A directory containing Java support libraries; JAR and ZIP files

• /opt/java/jdk: A symbolic link that points to the "primary" or default JDK installation

The use of the /opt/java directory is clearly optional, and it won't be found in any standard or specification (such as the Filesystem Hierarchy Standard mentioned in the "Filesystem Layout" section of Chapter 3). It's a technique that the author developed over time to support a large group of Java developers using Linux workstations, at a major corporation. The /opt/java directory simply makes it convenient to manage installations of vendors' JDKs, applications, and support files. Other administrators may prefer another solution (such as placing all files directly in /opt); in the end, it's a matter of taste. The purpose of this book is to provide examples and best practices; you should take this material and run with it, developing your own custom solutions.

Installing Multiple JDKs

Recall that one of the goals of this example Java installation is to make it quick and easy to actually use Java and Java applications. This means that individual users shouldn't have to make extensive configuration changes, edit many (if any!) shell scripts, and so on. However, this is (as it always is) at odds with the need for flexibility: If you install multiple vendors' JDKs, then obviously the user has to choose between them.

The compromise in this case is the /opt/java/jdk symbolic link (or symlink). This link points to one particular JDK installation that is designated to be the default JDK. For example, a given system might have three JDKs installed: the latest production-quality J2SDK from Sun, a JDK from IBM that is optimized for speed, and the absolute latest beta-quality J2SDK from Sun for testing. Most of the time, the developer will only want to use the latest release JDK, so the /opt/java/jdk link should point to that installation. In this example, there's only one JDK installed (namely, Sun's J2SDK), so the /opt/java/jdk link must point to it, which can be accomplished by issuing this command:

 % ln -s /opt/java/sun-j2sdk-1.4 /opt/java/jdk 

When a JDK is upgraded (perhaps when that beta-quality J2SDK is replaced by the next production release), it can simply be installed alongside the others, and the default JDK can be switched simply by updating the /opt/java/jdk symbolic link. However, it's crucial to remember that this only works if the users' environments actually point to /opt/java/jdk; obviously, if users have specific installations directly hard-coded into their environments, then changing /opt/java/jdk won't work. For this reason, all the user environment details described in the following sections are created to refer to /opt/java/jdk instead of a specific installation directory.

Installing JAR Files

The Java platform provides the ability to add support libraries for applications' use. These libraries are packaged either as ZIP-compressed files (which have an extension of .zip) or as Java Archive files. These libraries are similar in concept to the Unix dynamic libraries discussed in Chapter 7 and the Apache dynamically loadable modules discussed in Chapter 11.

These JAR files, however, must be explicitly made available to the Java Virtual Machine. Depending on the implementation of the JVM, there are typically a couple ways of doing this: most commonly, you'll either place the JARs in a specific directory known to the JVM, or add the names of JAR files to an environment variable (called the CLASSPATH variable.) Either way, there can quickly be an explosion of JAR files, with conflicting versions. This confusion of files is errorprone and can sometimes be very difficult to debug.

This is the motivation for the existence of the /opt/java/packages directory. Administrators place system-wide JAR and ZIP files in this directory, and the user environment will automatically set up the users' CLASSPATH variables to include the files. Adding a new file to /opt/java/packages will be picked up by the users' environments the next time they log in.

One issue with this approach, however, is that /opt/java must be owned by root; this means that average users can't place their own custom files in that directory. They'd have to manage their CLASSPATH on their own, which defeats the purpose of having a common /opt/java/package directory. To address this, the user environment scripts contained in the next section support not only the /opt/java/packages directory, but also a java/packages directory in the user's home directory. The scripts work identically on both of these directories, and they are complementary to each other. See the next section for more information.

Configuring the User Environment

The subdirectories of /opt/java work fine for organizing files, but they're useless unless the users' login environments are set up correctly. This section will present and discuss the necessary changes and scripts for configuring the users' environments for accessing the Java installation in /opt/java. Generally, there are only three things that need to be done: setting the users' CLASSPATH, adding the Java programs to the users' PATH, and setting the JAVA_HOME environment variable.

Setting the CLASSPATH

The CLASSPATH is an environment variable that instructs the Java Virtual Machine where to find JAR files. (Java is an object-oriented programming language, meaning that it operates on the notions of classes as a model of the software system. These classes are what is stored inside JAR and ZIP files, and so the path containing these libraries is known as the CLASSPATH.) The CLASSPATH is simply an environment variable whose value is a list of directories, ZIP files, and JAR files that contain Java classes, with each entry separated by colons.

In the earlier section, "Installing JAR Files", the directory /opt/java/packages was created as repository of JAR and ZIP files. Each file in this directory, then, must individually be added to the CLASSPATH variable. Additionally, whenever a new JAR file is added to (or removed from!) the directory, the CLASSPATH should be automatically adjusted, so that the administrator doesn't have to do it manually. By now, this problem should be familiar: It's the drop-in configuration problem, described extensively in Chapter 4!

The spirit of Unix is to never reinvent the wheel, so the easiest way to solve this problem is just to use the same techniques employed by Red Hat as described throughout Chapter 4. In fact, this problem is very simple to solve; the following shell script snippet in sh syntax (rather than csh syntax) will configure the CLASSPATH variable correctly:

 set CLASSPATH=. for jar in /opt/java/packages/*; do     set CLASSPATH=${CLASSPATH}:${jar} done export CLASSPATH 

The preceding fragment simply locates each JAR file in the /opt/java/packages directory and adds it to the CLASSPATH. The CLASSPATH starts out as a single dot("."). A path of ".", remember, is Unix shorthand for the current working directory, and so the fragment includes the current working directory as the first entry in the CLASSPATH. This is useful because it allows Java programs run from the command line to find classes that may be in the directory from which they were executed; this permits so-called anonymous Java classes to be located. (Don't worry if this doesn't make sense-it's not important to know how Java works. Just be sure to understand how the variable's getting set.) One final thing to note is that the code fragment adds any file or subdirectory in /opt/java/packages to the CLASSPATH; thus, Java libraries that are set up as flat directories rather than JAR or ZIP files will also work with the technique.

Recall that setting the CLASSPATH to include files in /opt/java/packages is only half the problem: Users will still need to modify their CLASSPATH to include specific files that they need themselves. However, the following similar example works for adding files from the users' own personal directories:

 set CLASSPATH=. if [ -d ${HOME}/java/packages ]; then       for jar in ${HOME}/java/packages; do           set CLASSPATH=${CLASSPATH}:${jar}       done fi export CLASSPATH 

This code snippet is almost identical to the previous case, except that it checks to make sure the user actually has a ~/java/packages directory before trying to add files from it. (The script can simply assume that /opt/java/packages is present, since it's global and managed by the system administrator.) Another thing to note is that the first line again globally resets the value of CLASSPATH; if you combine the two scripts, be sure to remove that line!

Setting the PATH and JAVA_HOME

The PATH variable is used by the shell to locate programs to execute; the JAVA_HOME variable simply needs to point to the directory where the J2SDK is installed. These are very simply variables to set; however, as was mentioned earlier, if they are set to point directly to a particular installation of a JDK (such as /opt/java/sun-jdk-1.4), then the script will have to be modified each time a JDK is upgraded.

One solution is quite simple: Just set these variables to point to the /opt/java/jdk symbolic link, rather than to a specific installation. Although this will work just fine, users who need to switch to a different JDK (other than the one indicated by /opt/java/jdk) will have to manually reset their PATHs. A more flexible solution is to allow the user a chance to override the default selection, by pointing to a specific installation. The following script fragment demonstrates this:

 if "X${JAVA_HOME}" == "X"; then      set JAVA_HOME=/opt/java/jdk fi set PATH=${PATH}:${JAVA_HOME}/bin export PATH JAVA_HOME 

This fragment simply sets the JAVA_HOME variable to the default /opt/java/jdk-but only if it's not already set!-and then adds an entry to the PATH relative to JAVA_HOME. To switch to a specific version of the J2SDK (or to another JDK), the user simply sets the JAVA_HOME variable and reexecutes the preceding script. It will pick up the custom JAVA_HOME and configure the environment appropriately.

Understanding JDKs

The example installation of a Java Development Kit in this section is based on an important assumption. The examples (especially the shell scripts) assume that the JDK being used works the same as Sun's reference J2SDK. The most common JDKs (such as IBM's version) do behave the same as Sun's; however, it's possible that some do not. Watch out for differences in behavior, and be prepared to tailor this example to the specific JDK being installed.

---