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. 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 using the JDK.
In this chapter you learn what 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 Developer’s Kit is the first step toward learning to program in Java.
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.
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 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 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 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:
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 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. To see the applet viewer in action, check out Figure 10.1.
FIGURE 10.1.
The MoleculeViewer applet running in the Java applet viewer.
Figure 10.1 shows the MoleculeViewer demo applet that comes with the JDK running in the 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.
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 36, “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 36 and get the whole scoop.
The Java class file disassembler (javap) is used to disassemble a class file. 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 only outputs the public member variables and methods. The -h option specifies that information be created that can be used in C header files. This is useful when you are attempting to interface C code to a Java class that you don’t have the source code for. You’ll learn much more about interfacing Java to C code in Chapter 38, “Native Methods and Libraries.”
The -classpath option specifies a list of directories to look for imported classes in. 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 to generate C source files from. The Options argument specifies how the source files are to be generated. You’ll learn how to use the Java header and stub file generator in Chapter 38. For that reason, you won’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 will create 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 37, “Java Documentation,” you’ll have to settle for this brief introduction for now. Or you could go ahead and jump to Chapter 37 to learn more.
The JDK comes with a variety of interesting Java demo applets, all including 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 discuss how they might impact the Web.
The first demo applet is the BarChart applet, which is shown in Figure 10.2.
FIGURE 10.2.
The Barchart Java applet.
The BarChart applet is a good example of how Java could 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 primitive shapes and more elaborate drawing routines. Figure 10.3 shows what the GraphicsTest applet looks like.
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 could come to life with graphical plots. SimpleGraph is shown in Figure 10.4.
FIGURE 10.3.
The GraphicsTest Java applet.
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 10.5.
FIGURE 10.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 waste time on the Web with Java games. The TicTacToe applet is shown in Figure 10.6.
FIGURE 10.6.
The TicTacToe Java applet.
The last applet you’re going to look at 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. It also has sound, so 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 10.7.
FIGURE 10.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 Developer’s 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 here 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 and see how something works. And Java is no exception. So, the API source code comes compressed in a file called src.zip, which is located in the java directory that was 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 Developer’s 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 Developer’s Kit is necessary to become a successful Java developer.
However, you shouldn’t stop with the Java Developer’s Kit. There are many third-party tools available and in the works that 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.
FIGURE 10.4.