Beginner's Guide to JDK

To complete the setup, you should modify your PATH environment variable to include the location of JDK wrappers. Using your favorite editor, edit the appropriate startup file (for me, this was .profile) and add /usr/local/jdk1.1.6/bin to your PATH. Adding this to the beginning of your current PATH setting ensures that this JDK is invoked.

You also need to add two new environment variables: JAVA_HOME and CLASSPATH.

JAVA_HOME tells JDK where its base directory is located. Although it isn't mandatory to set this variable since the JDK does a good job of determining this location, it is used by other Java programs such as the Swing Set.

CLASSPATH can be confusing and frustrating, but it is possible to use it well and correctly from the beginning. Just remember this simple analogy: CLASSPATH is for Java what PATH is for a shell on your machine. Looking closer at the analogy, your shell executes only those programs or scripts residing in the directory pointed to by PATH, unless the full path of the program is specified. CLASSPATH works the same way for Java. Only those applications and applets in the directories specified by the CLASSPATH environment variable can be run without specifying the complete location.

I usually set CLASSPATH to a simple dot. This lets me run any application that is in my current directory. I also create scripts that set my CLASSPATH on an “as needed” basis, depending on what I am doing during that particular session.

If you use bash as your shell, these three environment variables can be set as follows:

PATH=/usr/local/jdk1.1.6/bin:$PATH
CLASSPATH=.
JAVA_HOME=/usr/local/jdk1.1.3"
export PATH CLASSPATH JAVA_HOME

Note that the RPMs which come with Red Hat 4.1 and 4.2 do not work out of the box. I recommend erasing the RPMs and using the JDK distribution from Blackdown. Erase the RPMs with the commands rpm -e jdk and rpm -e kaffe.

You're now ready to test the JDK. Either log in or execute the startup file to set your new environment variables, and make sure the new environment variables are indeed taking effect. Executing rlogin localhost will do the trick.

Now, type java. A message giving usage parameters should appear. Typing javac should also work, displaying different usage parameters.

Next, use your favorite editor and type in your first Java program; name this file HelloLinux.java.

public class HelloLinux {
   public static void main (String args[]) {
      System.out.println("Hello Linux!");
      }
   }

To compile this program, type javac HelloLinux.java. The compilation process creates a single file called HelloLinux.class. To run your Java application, enter java HelloLinux. This outputs the single line “Hello Linux!”

The Linux kernel is capable of detecting Java byte code and automatically starting Java to run it. This eliminates the need to type java first. When the kernel is configured with Java support, you need do only two things. First, change permissions of your .class file to make it executable using the chmod command. Then, run it like any normal script or executable program.

For example, after compiling the Java program HelloLinux, perform the following commands:

chmod 755 HelloLinux.class
./HelloLinux.class

Note that you now have to specify the full name of the application. This includes the .class extension.

To set up Java support, you need the source code to the Linux kernel. The default installation of Caldera OpenLinux installs the kernel source code for you. Use this or download the latest and greatest kernel source and install it.

If you haven't compiled a kernel for your Linux box before, I recommend doing it once or twice to get a feel for it. This will also ensure that problems unrelated to Java don't arise when you are trying to add native Java support to the kernel.

Three steps are required to set up the kernel to automatically run Java byte code. You can find more information about using this feature of the kernel in Documentation/java.txt in your kernel source tree.

If you compiled Java support as a part of the kernel—i.e., it was not a module—then there is still another way to tell the kernel where your java wrapper lives. Log in as root and issue the command:

echo "/path/to/java/interpreter" >\
/proc/sys/kernel/java-interpreter