Java, Java, Java: The Java Development Kit

21. The Java Development Kit

The Java Development Kit (JDK) for JavaTM 2 Platform Standard Edition is a set of command-line tools for developing Java programs. It is available for free in versions for recent editions of Microsoft Windows, Linus, Macintosh OS X, and Solaris (Sun Microsystems).

Download information and documentation are available for the entire range of products associated with the JavaTM 2 Platform, Standard Edition (Java SE) at;

This appendix summarizes some of the primary tools available in the JDK. For more detailed information you should consult Sun’s Web site.

Table B.1 provides a summary of some of the JDK tools.

TABLE B.1 Tools included in the Java Development Kit.

Tool NameDescription

javacJava compiler. Translates source code into bytecode. javaJava interpreter. Translates and executes bytecode.

javadocJava documentation generator. Creates HTML pages from documentation comments embedded in Java programs.

appletviewerAppletviewer. Used instead of a browser to run Java applets. jarJava archive manager. Manages Java archive (JAR) files.

jdbJava debugger. Used to find bugs in a program.

javapJava disassembler. Translates bytecode into Java source code.

Sun Microsystems provides detailed instructions on how to install JDK for Java SE on computers running any of the above operating systems, including how to set the system’s PATH and CLASSPATH variables. Installation instructions can be located using the above link to downloading information.

The Java Compiler: javac

The Java compiler (javac) translates Java source files into Java bytecode. A Java source file must have the .java extension. The javac compiler will create a bytecode file with the same name but with the .class extension. The javac command takes the following form:

809

javac [ options ] sourcefiles [ files ]

The brackets in this expression indicate optional parts of the command. Thus, options is an optional list of command-line options (including the -classpath option), and files is an optional list of files, each of which contains a list of Java source files. The files option would be used if you were compiling a very large collection of files, too large to list each file individually on the command line.

Most of the time you would simply list the sourcefiles you are compiling imme- diately after the word javac, as in the following example:

Given this command, javac will read class definitions contained in MyAppletClass.java and MyHelperClass.java in the current working directory and translate them

into bytecode files named MyAppletClass.class and MyHelperClass.class. If a Java source file contains inner classes, these would be compiled into sepa-

rate class files. For example, if MyAppletClass.java contained an inner class named Inner, javac would compile the code for the inner class into a file named MyAppletClass$Inner.class.

If you are writing a program that involves several classes, it is not necessary to list each individual class on the command line. You must list the main class—that is, the class where execution will begin. The compiler will perform a search for all the other classes used in the main class. For example, if MyAppletClass uses an instance of MyHelperClass, you can compile both classes with the following command:

The Classpath

In this case, javac will perform a search for the definition of MyHelperClass.

How Java Searches for Class Definitions

When compiling a file, javac needs a definition for every class or interface that’s used in the source file. For example, if you are creating a subclass of java.applet.Applet, javac will need definitions for all of Applet’s super- classes, including Panel, Container, and Component. The definitions for these classes are contained in the java.awt package. Here’s how javac will search for these classes.

Javac will first search among its library files for definitions of classes, such as Applet and Panel. Next, javac will search among the files and directories listed on the user’s class path. The class path is a system variable that lists all the user directories and files that should be searched when compiling a user’s program. JDK no longer requires a class path variable. The class path can be set either by using the environment variable CLASSPATH or by using the -classpath option when invoking javac. By default, JDK will check in the current working directory for user classes. It doesn’t require that the CLASSPATH variable be set. If this variable is set, it must include the current directory. The preferred way to set the classpath is by using -classpath option. For example,

will tell javac to search in both the current directory (.) and in the ../source directory for user source files. Because the details for setting the CLASSPATH variable are system dependent, it’s best to consult the online installation docu- mentation to see exactly how this is done on your system.

During a successful search, javac may find a source file, a class file, or both. If it finds a class file but not source file, javac will use the class file. This would be the case for Java library code. If javac finds a source file but not a class file, it will compile the source and use the resulting class file. This would be the case for the first compilation of one of your source programs. If javac finds both a source and a class file, it determines whether the class file is up-to-date. If so, it uses it. If not, it compiles the source and uses the resulting class file. This would be the case for all subsequent compilations of one of your source programs.

As noted earlier, if your application or applet uses several source files, you need only provide javac with the name of the main application or applet file. It will find and compile all the source files, as long as they are located in a directory that’s listed in the class path.

The Java Interpreter: java

The java interpreter launches a Java application. This command takes one of the following forms:

java java

[ options ] [ options ]

classname

-jar

[ argument . . . ]

file.jar[ argument . . . ]

If the first form is used, java starts a Java runtime environment. It then loads the specified classname and runs that class’s main() method, which must be declared as follows:

The String parameter args[] is an array of strings, which is used to pass any

arguments listed on the command line. Command-line arguments are optional.

If the second form of the java command is used, java will load the classes and resources from the specified Java archive (JAR). In this case, the special -jar option flag must be specified. The options can also include many other command-line options, including the -classpath option.

The appletviewer

The appletviewer tool lets you run Java applets without using a Web browser. This command takes the following form:

appletviewer [ threads flag ] [ options ] url . . .

The optional threads flag tells Java which of the various threading options to use. This is system dependent. For details on this feature and the command line options, refer to Sun’s Web site.

The appletviewer will connect to one or more HTML documents specified by their Uniform Resource Locators (URLs). It will display each applet referenced in those documents in a separate window. Some example commands would be

In the first case, the document’s full path name is given. In the second case, since no host computer is mentioned, appletviewer will assume that the applet is located on the local host and will search the class path for myapplet.html.

AppletViewer tags

Once appletviewer retrieves the HTML document, it will find the applet by looking for either the object, embed, or applet tags within the document. The appletviewer ignores all other HTML tags. It just runs the applet. If it cannot find one of these tags, the appletviewer will do nothing. If it does locate an applet, it starts a runtime environment, loads the applet, and then runs the applet’s init() method. The applet’s init() must have the following method signature:

The applet Tag

The applet tag is the original HTML 3.2 tag used for embedding applets within an HTML document. If this tag is used, the applet will be run by the browser, using the browser’s own implementation of the Java Runtime Environment (JRE). Note, however, that if your applet uses the latest Java language features and the browser is not using the latest version of JRE, the applet may not run correctly. For example, this might happen if your applet makes use of Swing features that are not yet supported in the browser’s implementation of the JRE. In that case, your applet

won’t run under that browser.

To ensure that the applet runs with the latest version of the JRE—the one pro- vided by Sun Microsystems—you can also use the object or the embed tags. These tags are used to load the appropriate version of the JRE into the browser as a plugin module. A plugin is a helper program that extends the browser’s functionality.

The applet tag takes the following form:

You would use only the code or object attribute, not both. For the programs in this book, you should always use the code tag. The code tag specifies where the program will begin execution—that is, in the applet class.

The optional codebase attribute is used to specify a relative path to the applet. It may be omitted if the applet’s class file is in the same directory as the HTML document.

The width and height attributes specify the initial dimensions of the ap- plet’s window. The values specified in the applet tag can be overridden in the applet itself by using the setSize() method, which the applet inherits from the java.awt.Component class.

The param tags are used to specify arguments that can be retrieved when the applet starts running (usually in the applet’s init() method). The methods for retrieving parameters are defined in the java.applet.Applet class.

Finally, the alternative-text portion of the applet tag provides text that would be displayed on the Web page if the appletviewer or browser is unable to locate the applet.

Here’s a simple example of an applet tag:

In this case, the applet’s code is stored in a file name HelloWorld- Applet.class, which is stored in the classfiles subdirectory—that is, a sub- directory of the directory containing the HTML file. The applet’s window will be

200 200 pixels. And the applet is passed the name of the program’s author and date it was written. Finally, if the applet cannot be located, the “Sorry . . . ” message will be displayed instead.

The object Tag

The object tag is the HTML 4.0 tag for embedding applets and multimedia ob- jects in an HTML document. It is also an Internet Explorer (IE) 4.x extension to HTML. It allows IE to run a Java applet using the latest JRE plugin from Sun. The object tag takes the following form:

Note that parameters are used to specify your applet’s code and codebase. In ef- fect, these are parameters to the plugin module. An example tag that corresponds to the applet tag for the HelloWorldApplet might be as follows:

If the browser has an older version of the plug in than shown in the codebase attribute, the user will be prompted to download the newer version. If the browser has the same or newer version, that version will run. In theory Netscape 6 should also work the same as IE. For further details on how to use the object tag, see Sun’s plugin site at:

The embed Tag

The embed tag is Netscape’s version of the applet and object tags. It is in- cluded as an extension to HTML 3.2. It can be used to allow a Netscape 4.x browser to run a Java applet using the latest Java plugin from Sun. It takes the following form:

The type and pluginspage attributes are not used by the appletviewer, but they are necessary for browsers. They would just be ignored by the appletviewer.

For example, an embed tag for HelloWorldApplet would be as follows:

It may be possible to combine the applet, embed, and object tags in the same HTML file. Sun provides much more information, as well as demo programs on its plugin website: