Learning Java

Chapter 3. Tools of the Trade

You have many options for Java development environments, from the traditional text-editor-and-command-line environment to IDEs like WebGain’s Visual Café, Inprise’s JBuilder, Tek-Tools’ KAWA, or Sun’s Forte for Java. The examples in this book were developed using the Solaris and Windows versions of the Java Software Development Kit (SDK), so we will describe those tools here. When we refer to the compiler or interpreter, we’ll be referring to the command-line versions of these tools, so the book is decidedly biased toward those of you who are working in a Unix or DOS-like environment with a shell and filesystem. However, the basic features we’ll be describing for Sun’s Java interpreter and compiler should be applicable to other Java environments as well.

In this chapter, we’ll describe the tools you’ll need to compile and run Java applications. The last part of the chapter discusses how to pack Java class files into Java archives ( JAR files). Chapter 20, describes the ability to “sign” classes within a JAR file, and to give greater privileges to classes with a signature that you trust.

The Java Interpreter

A Java interpreter is software that implements the Java virtual machine and runs Java applications. It can be a standalone application like the SDK’s java program, or part of a larger application like the Netscape Navigator web browser. It’s likely that the interpreter itself is written in a native, compiled language for your particular platform. Other tools, like Java compilers and development environments, can be written in Java (and should be, we’d argue, in order to maximize the portability of the Java development environment). Sun’s Forte for Java is one example of a pure-Java IDE.

The Java interpreter performs all of the activities of the Java runtime system. It loads Java class files and interprets the compiled byte-code. It verifies compiled classes that are loaded from untrusted sources. In an implementation that supports dynamic, or just-in-time, compilation, the interpreter also serves as a specialized compiler that turns Java byte-code into native machine instructions.

Throughout the rest of this book, we’ll be building both standalone Java programs and applets. Both are kinds of Java applications run by a Java interpreter. The difference is that a standalone Java application has all of its parts; it’s a complete program that runs independently. An applet is more like an embeddable program module. The Java interpreter can’t run an applet directly, because it is used as part of a larger application. To run an applet, you can use a web browser like Sun’s HotJava or Netscape Navigator, or the appletviewer tool that comes with the SDK. Both HotJava and appletviewer are standalone Java applications run directly by the Java interpreter; these programs implement the additional structure needed to run Java applets.

Sun’s Java interpreter is called java . In a standalone Java application, one class includes a main( ) method, which contains the statements to be executed upon startup. To run the application, execute the interpreter, specifying that class as an argument. You can also specify options to the interpreter, as well as arguments to be passed to the application:

% java [interpreter options] class_name [program arguments]

The class should be specified as a fully qualified class name, including the package name, if any. Note, however, that you don’t include the .class file extension. Here are a few examples:

% java animals.birds.BigBird 
% java test

The interpreter searches for the class in the class path , a list of directories where packages of classes are stored. We’ll discuss the class path in detail in the next section. The class path is typically specified by an environment variable, which you can override with the command-line option -classpath .

After loading the class specified on the command line, the interpreter executes the class’s main( ) method. From there, the application can start additional threads, reference other classes, and create its user interface or other structures, as shown in Figure 3.1.

Figure 3-1. Starting a Java application

The main( ) method must have the right method signature . A method signature is a collection of information about the method, like a C prototype or a forward function declaration in other languages. It includes the method’s name, type, and visibility, as well as its arguments and return type. The main( ) method must be a public, static method that takes an array of String objects as its argument and does not return any value (void):

public static void main ( String [] myArgs )

Because main( ) is a public and static method, it can be accessed directly from another class using the name of the class that contains it. We’ll discuss the implications of visibility modifiers such as public and the meaning of static in Chapter 4 through Chapter 6.

The main( ) method’s single argument, the array of String objects, holds the command-line arguments passed to the application. As in C, the name that we give the parameter doesn’t matter; only the type is important. Unlike C, the content of myArgs is a true array. There’s no need for an argument count parameter, because myArgs knows how many arguments it contains and can happily provide that information:

int argc = myArgs.length;

Java also differs from C in another respect here: myArgs[0] is the first command-line argument, not the name of the application. If you’re accustomed to parsing C command-line arguments, you’ll need to be careful not to trip over this difference.

The Java interpreter continues to run until the main( )method of the initial class file has returned, and until any threads that it started are complete. Special threads designated as “daemon” threads are silently killed when the rest of the application has completed.