Server-Side Java with Jakarta-Tomcat

When I began to write server-side web applications, there were two mainstream choices: if you wanted the program to execute quickly, you chose C, and if you wanted to write the program quickly, you used Perl. C, as we all know, is great when the binary needs to be small, fast and efficient. But C's lack of automatic memory management and decent string handling, along with the extreme care that programmers need in order to use it, made it a poor second choice when compared with Perl.

But in the last few years, a number of programming languages have begun to challenge Perl for the server-side web programming mantle. In particular, Python has gained significant ground, thanks in no small part to the growth of the Zope web development environment.

But perhaps the largest groundswell of server-side programming is coming from the Java community. Java, as many of us might remember, began life as a client-side programming language. For the most part, applets are an unpleasant memory of what happens when you try to mix two client-side paradigms—a lesson that the increasingly common use of Flash seems to ignore.

The basic unit of server-side Java is the servlet, a small program that is executed in response to an HTTP request and that generates a legal HTTP response. Since servlets are written in Java, they are written as object classes, inherit from a servlet ancestor and can take advantage of Java's threading and exception handling. Moreover, servlets (like all Java programs) run inside of a Java virtual machine (JVM), an abstraction layer that can run on any operating platform. This means that the same servlets can run on nearly any operating system, providing even greater portability than CGI programs.

I have used servlets in a small number of projects so far, but this number is rising rapidly. Java is now the “in” language. This is partly because Sun has invested a large amount in its marketing, partly because it offers some technological and infrastructural advantages over its rivals and also because it poses a serious platform challenge to Windows. In addition, server-side Java is the cornerstone for an increasing number of Java-based application servers.

This month, we will begin to explore Java as a server-side programming language. As a beginning step, we will install the Jakarta-Tomcat environment for running servlets, as well as the associated Jasper environment for creating Java Server Pages (JSPs). In coming months, we will look at how to connect our servlets and JSPs to a relational database, as well as how to use Enterprise JavaBeans and the Enhydra application server for an even more powerful environment.

When I first started to work with Java on Linux a few years ago, the situation seemed fairly grim: while Linux was the best known, open-source operating system, and Sun was promoting Java as a universal programming language, it was difficult to impossible to get a good version of Java for Linux. Some volunteer porting efforts, particularly the one done by the Blackdown porters, were impressive, but installation was prone to problems and not nearly as stable as developers might have liked.

As I write this article in January 2001, the situation has changed dramatically: you can now download a Linux version of the latest Java development kit (JDK) directly from Sun's web site. Further, the Tomcat servlet/JSP system works just fine on Linux. As Linux picks up more steam, it is becoming an increasingly attractive platform on which to program in Java.

Because my main Linux box runs Red Hat 6.2, I downloaded the JDK 1.3 RPM from Sun's web site, http://java.sun.com/. In order to download the JDK, I had to sign up as a member of the “Java Developer Connection”; while I'm not thrilled by the notion of having to register in order to download software, it does not seem like a terrible price to pay. The RPM cannot be installed directly; first, you must agree to Sun's Java licensing agreement.

Once you have accepted the agreement, the RPM is unpacked and made available for install. You can then log in as root and install the JDK, which is placed in the /usr/java directory. By putting /usr/java/jdk1.3/bin/ in your PATH environment variable, you can execute the javac compiler and the java runtime environment without having to specify an explicit path.

Once you have installed the JDK, you should run at least one simple test to ensure that it works. Listing 1 contains a simple program that can be invoked without any parameters and prints “hello, world” to STDOUT. If the program is passed through any parameters, it prints those parameters separated by a pipe character (|).

Listing 1. Test.java

To compile our test class (Test.java) into bytecodes (Test.class), use the Java compiler, javac:

javac Test.java

To run the program, we must invoke the Java runtime environment (java), giving it the name of our class (without the .class suffix):

java Test

Hello, world

java Test a b "q r s" 123

a|b|q r s|123

export JAVA_HOME=/usr/java/jdk1.3