by Michael Morrison
The Java Developers Kit (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. Although some of the tools are discussed in more detail in later chapters, this chapter gives you a broad perspective on using the tools to develop Java programs with the JDK.
In this chapter, you learn which tools are shipped in the JDK and how they are used in a typical Java development environment. With the information presented in this chapter, you will be well on your way to delving further into Java development; the Java Developers Kit is the first step toward learning to program in Java.
Before you get started learning about the Java Developers Kit, it's important to make sure that you have the latest version. As of this writing, the latest version of the JDK is release 1.02. Version 1.1 is expected in the very near future; you can check Sun's Java Web site at http://www.javasoft.com/ to see what the latest version is. 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, still in a state of rapid change. Be sure to keep an eye on the Java Web site for the latest information.
The JDK version 1.0.2 for Windows 95, Windows NT, Macintosh, and Solaris is provided on the CD-ROM that accompanies this book.
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.
The Java Developers Kit contains a variety of tools and Java development information. Following is a list of the main components of the JDK:
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.
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 SomeFile.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:
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 have 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 only default function is to 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 redefine 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 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 it is possible for a single Java
source code file to compile into multiple executable class files.
When this happens, it means that the source file contains multiple
class definitions.
| Note |
Even though Java source files and classes are typically given the extensions .java and .class, it is important to note that some operating systems aren't capable of fully representing these extensions because of their length. For example, Windows 3.1 is limited to three character extensions, in which case Java source files and classes use the extensions .jav and .cla. |
| Note |
Even though you are allowed to include multiple classes in a single Java source code file, only one of them can be declared as public. This means that any other classes defined in the file must be private support classes used only by the public class. You learn all about public and private classes in Chapter 6, "Java Language Fundamentals." |
The Java compiler is a command-line utility that works in a manner similar 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:
The -classpath option tells the compiler to override the CLASSPATH environment variable with the path specified by Path. Use of this option 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 classes are frequently 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 is 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 generate only 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. In general, it isn't a good idea to suppress warnings using the -nowarn option because warnings can be useful in pointing out problems in your code. The -verbose option has a somewhat 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. You learn all about optimization in Chapter 30, "Optimizing Java Code."
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 using a full-blown Web browser. 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. To see the applet viewer in action, check out Figure 4.1.
Figure 4.1: The MoleculeViewer applet running in the Java applet viewer.
Figure 4.1 shows the MoleculeViewer demo applet (which comes with the JDK) running in the applet viewer.This program was launched in the applet viewer by changing to the directory containing the MoleculeViewerHTML 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.
The Java debugger (jdb) is a command-line utility that enables you to debug Java applications. The Java debugger uses the Java Debugger API to provide debugging support within the Java runtime interpreter. The syntax for using the Java debugger follows:
jdb Options
The Options argument is used to specify different settings within a debugging session. Because the Java debugger is covered in detail in Chapter 28, "Java Debugging," you won't learn any more details about it in this chapter. If you are just dying to know more about Java debugging, feel free to jump ahead to Chapter 28 and get the whole scoop.
The Java class file disassembler (javap) is used to disassemble executable Java class files. Its default output consists of the public data and methods for a class. The class file disassembler is useful in cases where you don't have the source code for a class, but you'd like to know a little more about how it is implemented. The syntax for the disassembler follows:
javap Options ClassNames
The ClassNames argument specifies the names of one or more classes to be disassembled. The Options argument specifies how the classes are to be disassembled. The disassembler supports the following options:
The -c option tells the disassembler to output the actual bytecodes for each method. The -p option tells the disassembler to also include private variables and methods in its output. Without this option, the disassembler outputs only the public member variables and methods. The -h option specifies that information be created that can be used in C header files-useful when you are attempting to interface C code to a Java class for which you don't have the source code. You'll learn much more about interfacing Java to C code in Chapter 33, "Integrating Native Code."
The -classpath option specifies a list of directories in which to look for imported classes. The path given by Path overrides the CLASSPATH environment variable. The -verify option tells the disassembler to run the verifier on the class and output debugging information. Finally, the -version option causes the disassembler to print its version number.
The Java header and stub file generator (javah) is used to generate C header and source files for implementing Java methods in C. The files generated can be used to access member variables of an object from C code. The header and stub file generator accomplishes this by generating a C structure whose layout matches that of the corresponding Java class. The syntax for using the header and stub file generator follows:
javah Options ClassName
The ClassName argument is the name of the class from which to generate C source files. The Options argument specifies how the source files are to be generated. Because you learn how to use the Java header and stub file generator in Chapter 33, "Integrating Native Code," you don't get into it in any more detail in this chapter.
The Java documentation generator (javadoc) is a useful tool for generating API documentation directly from Java source code. The documentation generator parses through Java source files and generates HTML pages based on the declarations and comments. The syntax for using the documentation generator follows:
javadoc Options FileName
The FileName argument specifies either a package or a Java source code file. In the case of a package, the documentation generator creates documentation for all the classes contained in the package. The Options argument enables you to change the default behavior of javadoc.
Because the Java documentation generator is covered in detail in Chapter 29, "Documenting Your Code," you'll have to settle for this brief introduction for now. Or you could jump to Chapter 29 to learn more.
The JDK comes with a variety of interesting Java demo applets, all of which include complete source code. Following is a list of the demo Java applets that come with the JDK:
Rather than go through the tedium of describing each of these applications, I'll leave most of them for you to explore and try out on your own. However, it's worth checking out a few of them here and discussing how they might impact the Web.
The first demo applet is the BarChart applet, shown in Figure 4.2.
Figure 4.2: The BarChart Java applet.
The BarChart applet is a good example of how Java can be used to show statistical information on the Web graphically. The data represented by the bar graph could be linked to a live data source, such as a group of stock quotes. Then you could actually generate a live, to-the-minute, dynamically changing stock portfolio.
The GraphicsTest applet is a good example of how to use Java graphics. Java includes an extensive set of graphics features, including support for drawing primitive shapes as well as more elaborate drawing routines. Figure 4.3 shows what the GraphicsTest applet looks like.
Figure 4.3: The GraphicsTest Java applet.
Keeping the focus on graphics, the SimpleGraph applet shows how Java can be used to plot a two-dimensional graph. There are plenty of scientific and educational applications for plotting. Using Java, data presented in a Web page can come to life with graphical plots. SimpleGraph is shown in Figure 4.4.
Figure 4.4: The SimpleGraph Java applet.
On the business front, there's nothing like a good spreadsheet. The SpreadSheet Java applet shows how to implement a simple spreadsheet in Java. I don't think I even need to say how many applications there are for interactive spreadsheets on the Web. Check out the SpreadSheet applet in Figure 4.5.
Figure 4.5: The Spreadsheet Java applet.
Once you've gotten a headache playing with the SpreadSheet applet, it's time to blow off a little steam with a game. The TicTacToe applet demonstrates a simple Java version of TicTacToe. This demo opens a new window of opportunity for having fun on the Web. Games will no doubt be an interesting application for Java, so keep your eyes peeled for new and interesting ways to have fun on the Web with Java games. The TicTacToe applet is shown in Figure 4.6.
Figure 4.6: The TicTacToe Java applet.
The last applet mentioned in this chapter is the UnderConstruction applet, which is a neat little applet that can be used to jazz up unfinished Web pages. This applet shows an animation of the Java mascot, Duke, with a jackhammer. Because the applet also has sound, it's a true multimedia experience! Although this applet is strictly for fun, it nevertheless provides a cool alternative to the usual "under construction" messages that are often used in unfinished Web pages. The UnderConstruction applet is shown in Figure 4.7.
Figure 4.7: The UnderConstruction Java applet.
Although running these demo applets is neat, the real thing to keep in mind is that they all come with complete source code. This means that you can rip them apart and figure out how they work, and then use similar techniques in your own Java programs. The most powerful way to learn is by example, and the demo applets that come with the JDK are great examples of robust Java applets.
The final component of the Java Developers Kit is the source code for the Java API. That's right-the JDK comes with the complete source code for all the classes that make up the Java API. Sun isn't concerned with keeping the internals of Java top secret. They followed the lead of the UNIX world and decided to make Java as available and readily understood as possible. Besides, the real value of Java is not the specific code that makes it work, it's the idea behind it.
The API source code is automatically installed to your hard drive when you decompress the JDK, but it remains in compressed form. The assumption is that not everyone is concerned about how the internals of Java are implemented, so why waste the space. However, it is sometimes useful to be able to look under the hood to see how something works. Because Java is no exception, the API source code comes compressed in a file called src.zip, located in the java directory created on your hard drive during installation of the JDK. All the classes that make up the Java API are included in this file.
The Java Developers Kit provides a wealth of information, including the tools essential to Java programming. In this chapter, you learned about the different components of the JDK, including tools, applet demos, and the Java API source code. Although you learn more about some of these tools throughout the rest of the book, it's important to understand what role each tool plays in the development of Java programs. A strong knowledge of the information contained in the Java Developers Kit is necessary to becoming a successful Java developer.
However, you shouldn't stop with the Java Developers Kit. Many third-party tools are available or are in the works to supplement the JDK and enable you to put together a more complete Java programming toolkit. The next chapter highlights these tools and describes how they impact Java development now, and what they may mean for the future.