All Categories :
Java
Chapter 4
The Java Developers Kit
by Michael Morrison
CONTENTS
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
- 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.
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:
- -debug
- -checksource (equivalent
to -cs)
- -classpath Path
- -verbose (equivalent
to -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 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:
- -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.
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:
- -c
- -p
- -h
- -classpath Path
- -verify
- -version
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:
- Animator
- ArcTest
- BarChart
- Blink
- BouncingHeads
- CardTest
- DitherTest
- DrawTest
- Fractal
- GraphicsTest
- GraphLayout
- ImageMap
- ImageTest
- JumpingBox
- MoleculeViewer
- NervousText
- ScrollingImages
- SimpleGraph
- SpreadSheet
- TicTacToe
- TumblingDuke
- UnderConstruction
- WireFrame
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.
Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.