Java Developer Kit

The Java Developer's Kit, or JDK, is a comprehensive set of tools, utilities, documentation, and sample code for developing Java programs. Without it, you wouldn't be able to do much with Java. This chapter focuses on the JDK and the tools and information supplied with it.

Getting the Latest Version

Before you get started learning about the Java Developer's Kit, it's important to make sure that you have the latest version. As of this writing, the latest version of the JDK is the final release 1.

This version will probably be around for a while, so you're probably OK. Just to be sure, you can check Sun's Java Web site to see what the latest version is. The URL for this site follows: http://www.javasoft.com/

This Web site provides all the latest news and information regarding Java, including the latest release of the JDK. Keep in mind that Java is a new technology that is still in a state of rapid change. Be sure to keep an eye on the Java Web site for the latest information.

The JDK usually comes as a compressed self-extracting archive file. To install the JDK, simply execute the archive file from the directory where you want the JDK installed.

The archive will automatically create a java directory within the directory you extract it from, and build a directory structure to contain the rest of the JDK support files. All the related files are then copied to the correct locations in the JDK directory structure automatically.

Overview

The Java Developer's Kit contains a variety of tools and Java development information. Following is a list of the main components of the JDK:

• The Runtime Interpreter
• The Compiler
• The Applet Viewer
• The Debugger
• The Class File Disassembler
• The Header and Stub File Generator
• The Documentation Generator
• Applet Demos
• API Source Code

The runtime interpreter is the core runtime module for the Java system.

The compiler, applet viewer, debugger, class file disassembler, header and stub file generator, and documentation generator are the primary tools used by Java developers.

The applet demos are interesting examples of Java applets, which all come with complete source code. And finally, if you are interested in looking under the hood of Java, the complete source code for the Java API (Application Programming Interface) classes is provided.

Oxxus supports all the newest JDK from 1.4 to 1.7 with JRockit as a special edition. View our java hosting offer.

The Runtime Interpreter

The Java runtime interpreter (java) is a stand-alone version of the Java interpreter built into the HotJava browser. The runtime interpreter provides the support to run Java executable programs in compiled, bytecode format.

The runtime interpreter acts as a command-line tool for running nongraphical Java programs; graphical programs require the display support of a browser. The syntax for using the runtime interpreter follows:

java Options Classname Arguments

The Classname argument specifies the name of the class you want to execute. If the class resides in a package, you must fully qualify the name. For example, if you want to run a class called Roids that is located in a package called ActionGames, you would execute it in the interpreter like this:

java ActionGames.Roids

When the Java interpreter executes a class, what it is really doing is executing the main method of the class. The interpreter exits when the main method and any threads created by it are finished executing.

The main method accepts a list of arguments that can be used to control the program. The Arguments argument to the interpreter specifies the arguments passed into the main method.

For example, if you have a Java class called TextFilter that performs some kind of filtering on a text file, you would likely pass the name of the file as an argument, like this:

java TextFilter SomeFilex.txt

The Options argument specifies options related to how the runtime interpreter executes the Java program. Following is a list of the most important runtime interpreter options:

• debug
• checksource, -cs
• classpath Path
• verbose, -v
• verbosegc
• verify
• verifyremote
• noverify
• DPropertyName=NewValue

The -debug option starts the interpreter in debugging mode, which enables you to use the Java debugger (jdb) in conjunction with the interpreter.

The -checksource option causes the interpreter to compare the modification dates of the source and executable class files. If the source file is more recent, the class is automatically recompiled.

*NOTE The -checksource and -verbose options provide shorthand versions, -cs and -v. You can use these shorthand versions as a convenience to save typing.

The Java interpreter uses an environment variable, CLASSPATH, to determine where to look for user-defined classes. The CLASSPATH variable contains a semicolon-delimited list of system paths to user-defined Java classes. Actually, most of the Java tools use the CLASSPATH variable to know where to find user-defined classes.

The -classpath option informs the runtime interpreter to override CLASSPATH with the path specified by Path.

The -verbose option causes the interpreter to print a message to standard output each time a Java class is loaded. Similarly, the -verbosegc option causes the interpreter to print a message each time a garbage collection is performed.

A garbage collection is performed by the runtime system to clean up unneeded objects and to free memory.

The -verify option causes the interpreter to run the bytecode verifier on all code loaded into the runtime environment. The verifier's default function is to only verify code loaded into the system using a class loader.

This default behavior can also be explicitly specified using the -verifyremote option.

The -noverify option turns all code verification off.

The -D option enables you to redefined property values. PropertyName specifies the name of the property you want to change, and NewValue specifies the new value you want to assign to it.

The Compiler

The Java compiler (javac) is used to compile Java source code files into executable Java bytecode classes. In Java, source code files have the extension .java.

The Java compiler takes files with this extension and generates executable class files with the .class extension.

The compiler creates one class file for each class defined in a source file. This means that many times a single Java source code file will compile into multiple executable class files. When this happens, it means that the source file contains multiple class definitions.

The Java compiler is a command-line utility that works similarly to the Java runtime interpreter. The syntax for the Java compiler follows:

javac Options Filename

The Filename argument specifies the name of the source code file you want to compile. The Options argument specifies options related to how the compiler creates the executable Java classes. Following is a list of the compiler options:

• -classpath Path
• -d Dir
• -g
• -nowarn
• -verbose
• -O

The -classpath option tells the compiler to override the CLASSPATH environment variable with the path specified by Path. This causes the compiler to look for user-defined classes in the path specified by Path.

The -d option determines the root directory where compiled classes are stored. This is important because many times classes are organized in a hierarchical directory structure.

With the -d option, the directory structure will be created beneath the directory specified by Dir. An example of using the -d option follows:

javac -d ..\ Flower

In this example, the output file Flower.class would be stored in the parent directory of the current directory. If the file Flower.java contained classes that were part of a package hierarchy, the subdirectories and output classes would fan out below the parent directory.

The -g compiler option causes the compiler to generate debugging tables for the Java classes. Debugging tables are used by the Java debugger, and contain information such as local variables and line numbers.

The default action of the compiler is to only generate line numbers.

The -nowarn option turns off compiler warnings. Warnings are printed to standard output during compilation to inform you of potential problems with the source code.

It is sometimes useful to suppress warnings by using the -nowarn option. The -verbose option has somewhat of an opposite effect as -nowarn; it prints out extra information about the compilation process.

You can use -verbose to see exactly what source files are being compiled.

The -O option causes the compiler to optimize the compiled code. In this case, optimization simply means that static, final, and private methods are compiled inline.

When a method is compiled inline, it means that the entire body of the method is included in place of each call to the method. This speeds up execution because it eliminates the method call overhead.

Optimized classes are usually larger in size, to accommodate the duplicate code. The -O optimization option also suppresses the default creation of line numbers by the compiler.

The Applet Viewer

The applet viewer is a tool that serves as a minimal test bed for final release Java applets. You can use the applet viewer to test your programs instead of having to wait for HotJava to support the final release of Java.

Currently, the applet viewer is the most solid application to test final release Java programs, because the HotJava browser still only supports alpha release applets. You invoke the applet viewer from a command line, like this:

appletviewer Options URL

The URL argument specifies a document URL containing an HTML page with an embedded Java applet. The Options argument specifies how to run the Java applet.

There is only one option supported by the applet viewer, -debug. The -debug option starts the applet viewer in the Java debugger, which enables you to debug the applet.

The MoleculeViewer applet running in the Java applet viewer.

This program was launched in the applet viewer by changing to the directory containing the MoleculeViewer HTML file and executing the following statement at the command prompt:

appletviewer example1.html

example1.html is the HTML file containing the embedded Java applet. As you can see, there's nothing complicated about running Java applets using the applet viewer. The applet viewer is a useful tool for testing Java applets in a simple environment.