|
Articles Index
2:
Tools and Configuration
By Steve Meloan
December 1998
Sun Microsystems' release of the
Java 2 platform marks the dawn of
a new era in Java development--one of far greater significance than
the original JDK 1.2 nomenclature
implied. Now that the Java 2 platform has made its official debut at
the Java Business Expo in New York, developers can explore the truly
sweeping scope and capabilities of this new release.
In addition to the Java 2 platform's many changes and enhancements at the
programming level, there have also been significant changes made in terms
of tools, set-up, and system configuration. This article details many
of these diverse changes and offers a historical perspective.
The areas covered are:
Execution and Configuration
First, the jre command has been eliminated. This was once an
alternative to using java as a means of starting a Java
program. The jre command was part of the Java Runtime
Environment, but with the Java 2 platform, the runtime and development
environments have effectively merged.
Also, the classes.zip file has been eliminated, and the
associated use of the classpath has significantly changed.
Classpath Background
With JDK 1.1, the default classpath value indicated the path where the Java
system classes resided (classes.zip), along with the current
working directory ("."). Either the -classpath
flag, or the CLASSPATH environment variable could be used to
add a new library location to the classpath, to expand upon the core set of
libraries provided for by the JDK.
If the CLASSPATH environment variable was set, the effective
classpath would still contain the classes.zip file (as in the
default setting), but with the newly assigned value in place of the current
working directory.
If, on the other hand, the -classpath option was used, the
<path> values had to explicitly contain both the original
classes.zip reference, and the new application classes:
C:> java -classpath
C:\jdk-path\lib\classes.zip;\app\classes Application
This discrepancy between the two means of setting the classpath caused a
great deal of confusion--along with outright errors. Often, the explicitly
specified version of classes.zip did not match the version of
the java command being used.
Thankfully, this anomaly has been rectified with the Java 2 platform. The
-classpath option now has the same functionality as the
CLASSPATH environment variable. But the single search path
once specified by the classpath, has been broken down into three distinct
areas--which will be discussed in the following sections.
New Class Search Paths
With the Java 2 platform, the system classes no longer reside in a zip file
(a good idea, considering occasional misguided attempts at unzipping the
file). They're now stored in a Java Archive (jar) file. The runtime
classes are found in the file rt.jar (located in the
jre/lib directory), while the JDK-supported tool classes are
found in the tools.jar file (located in the lib
directory).
Also, the system class files are no longer specified by either
CLASSPATH or -classpath. Instead, the location
is specified automatically by the runtime environment (see
sun.boot.class.path property). This default can be changed
with the Xbootclasspath compile time flag:
-Xbootclasspath:paths/files. But it's important to remember
when using this flag to also include the default rt.jar file.
With the Java 2 platform, the only classes trusted by the runtime, are
those in the boot classpath. Thus, by explicitly adding something to the
system classpath it becomes trusted. With the old JDK 1.1, anything loaded
locally from classpath became trusted.
Two other jar files ship with the Java 2 platform--the
il8n.jar, which provides internationalization support classes
(similar to the java.text.resources subpackage), and the
jaws.jar file, which provide capabilities such as JavaScript
integration with Netscape's JSObject, along with
JSException classes, and browser plug-in interoperability.
Both the il8n.jar and jaws.jar files are found in
the jre/lib directory.
Extensions Framework
While CLASSPATH or -classpath can still be used
to add nonsystem libraries, this process, too, has been greatly simplified
with the Java 2 platform. Simply place a jar file in the
lib/ext directory, under the Java runtime directory
(jre/lib/ext with the JRE), and the library is added. The
lib/ext directory is included in the system policy file, and
is given all permissions.
For those classes not contained in a jar file, they can be added simply by
placing them in the classes directory--also found under the
Java runtime directory (jre/classes). Note, however, that
this directory does not exist by default.
Any native libraries that are installed with an extension are stored in the
following directories:
Solaris: $JAVA_HOME.lib/<arch>
(sparc, intel, etc.)
Windows: $JAVA_HOME/bin
The new Extensions Framework also directs its attention to downloadable
extensions. To use a library within an applet, the library file can be
specified in a special Class-Path: line in the manifest file
of the applet's jar file. This is a handy alternative to either storing
everything in one very large jar file, or specifying multiple jar files
within the <APPLET> tag (both of which can still be
done).
Below is a sample Class-Path manifest file entry--adding jar
files to the normal classpath as extensions:
Class-Path: someJar.jar stuff/more.jar
Once the extension is found, it is downloaded and placed into a namespace
in memory. Such downloaded extensions are purely temporary, however.
Also, they cannot use native code, and must be signed or loaded from a
trusted source to gain permission to perform system-level actions.
Search Paths Summary
In summary, three basic search paths are now used to find classes:
(The properties below can only be examined from a trusted program.)
- The first location searched is the boot classpath.
This can be set using the
-Xbootclasspath
option, and can be examined by calling
System.getProperty("sun.boot.class.path").
- The second location searched is the extension directories
(
jre/lib/ext). The list of directories can be
examined by calling System.getProperty("java.ext.dirs").
- The third and final location searched is the application classpath,
set by either
-classpath or CLASSPATH.
The value of this path can be examined by calling
System.getProperty("java.class.path").
File Structure
The Java 2 platform software has the following directory structure (not
comprehensive):
jdk1.2
___________|________________
| | |
bin lib jre
| | _______|__________
java.exe tools.jar | |
javac.exe lib bin
javap.exe / \ / \
javah.exe ext rt.jar classic java.exe
javadoc.exe / i18n.jar / java.dll
iiimp.jar jvm.dll awt.dll
|
Just-In-Time Compiler
Sun's JREs now come with a just-in-time (JIT) compiler for both Windows and
Solaris. The Windows version is provided by Symantec, but an alternative
version is also available from Inprise.
A JIT compiler speeds performance by compiling Java platform-neutral
byte-code into a machine-specific native instruction set. The JIT
conversion only occurs the first time the code is encountered, and the
output is then stored in a runtime cache. The JIT compiler has to be smart
enough to only compile that which is worth compiling. Compilation of a
one-time block of initialization code would likely take longer than the
execution of the raw byte-code.
The default JIT compiler is located at:
jre/bin/symjit.dll
To determine the version of the JIT compiler being used, set the
JAVA_COMPCMD environment variable to FORCE_SIGNON.
Disabling the JIT compiler can sometimes be useful in that it allows seeing
source code line numbers when an unexpected exception is thrown. There are
two ways the JIT compiler can be disabled:
By setting the JAVA_COMPILER environment variable to
NONE:
set JAVA_COMPILER=NONE
By setting the system property java.compiler to NONE:
java -Djava.compiler=NONE myapp
The JIT compiler was previously disabled by using the -nojit
option:
java -nojit myapp (NOTE: This is no longer valid!)
The JAVA_COMPILER or java.compiler settings can
also be used to specify an alternate JIT compiler:
set JAVA_COMPILER=foo.dll
or
java -Djava.compiler=foo.dll myapp
The search for the alternative compiler is made in the jre\bin
directory and on the system's PATH. If no such compiler is
found, the virtual machine will default to using the interpreter.
Native Threads in Solaris
The Java 2 platform now offers native-thread support on the Solaris
platform. With the original (and still default) green threads, a Java
program creates and controls multiple threads executing within a single
CPU. But in native mode, the system can schedule threads across multiple
CPUs, significantly speeding processing.
The threads option can either be set using command line options:
java -native myapp
java -green myapp
Or by setting the environment variable THREADS_FLAG to either
native or green.
Debug
When set to any value, the _JAVA_LAUNCHER_DEBUG environment
variable causes the JRE to generate numerous debug messages at
startup--often useful in resolving configuration problems.
Security/Signing Tools
Security is one of the main areas impacted by the Java 2 platform. The new
security model offers fine-grain, highly configurable, flexible, and
extensible access control. And access control can now not only be offered
for applets, but for any code written in the Java language--from
applications to beans. Significant enhancements have also been made in
terms of the Java Cryptography Architecture (JCA), including third-party
cryptographic services, key management, and an upgrade to the certificate
management infrastructure to support X.509 v3 certificates.
In the JDK 1.1, the javakey tool handled all security-related
and code-signing tasks. With the Java 2 platform, these functions have
been broken down into two distinct tools--keytool (for key
generation in certificate management) and jarsigner (for
signing of jar files).
The original key database from JDK 1.1 has been renamed
.keystore, and has been moved to the user's home directory.
Keystore is password protected, and requires a six character or greater
password. The original key file, identitydb.obj, has been
eliminated entirely.
When keytool is run for the first time, it creates a private
key and a certificate (holding a public key) for the entity specified. If
an explicit entity name is not specified, it defaults to "mykey".
The private key created will always be password protected and the entire
keystore can also be protected if desired (a good idea!).
Here is a sample of running keytool to generate the key pairs:
keytool -genkey
Enter keystore password: chilidog
What is your first and last name?
[Unknown]: Steve Meloan
What is the name of your organizational unit?
[Unknown]: Education
What is the name of your organization?
[Unknown]: Meloan Publishing
What is the name of your City or Locality?
[Unknown]: San Francisco
What is the name of your State or Province?
[Unknown]: California
What is the two-letter country code for this unit?
[Unknown]: US
Is <CN=Steve Meloan, OU=Education,
O=Meloan Publishing,
L=San Francisco, S=California, C=US> correct?
[no]: Yes
|
The policytool, meanwhile, supports the Java 2 platform's
expanded security capabilities. In contrast to the old sandbox model,
security now offers fine-grained permissions for specific operations. The
GUI-driven policytool program grants or refuses permissions
based upon such criteria as who signed a given class, or where it was
loaded from. When it comes time to execute a privileged code block, the
new access controller consults the policy database to see if the code has
the necessary permissions.
The Java 2 platform includes many cryptographic services that go well
beyond the MessageDigest, Signature, and
KeyPairGenerator capabilities of JDK 1.1. These include an
X.509 version 3 implementation of a new Certificate interface, additional
support for managing the keystore, and key factory support for converting
between different key representations.
It's also now possible to set applications to run with the same security
manager as applets. Simply set the java.security.manager
system property from the command line and everything will then go through
the access controller.
java -Djava.security.manager MyClass
Unless explicitly defined as above, there is no security manager for Java
applications.
New Jar Command Options
The jar command has two important new command-line options.
With the -u option, a file can either be added or replaced
into an already existing jar file, making it no longer necessary to
re-create the entire jar file from scratch.
Normal jar file creation:
jar cvf MyJar.jar First.class
Subsequent update of jar file:
jar uvf MyJar.jar Second.class
A second command option allows the changing of directories during the
creation or update of a jar file. The following command
"jar"s together files from several different
directories:
jar cf cookie.jar -C first first/*.class -C ../second second/*.class
-C ../third third/*.class
Also, as part of the Java Extensions framework, it's possible to execute a
program encapsulated in a jar file by using the -jar flag with
the java command.
The target startup class is first specified by the Main-Class
manifest header in the manifest file of the jar file.
For example, for a class Foo.class, a manifest file,
manifest.mf, would be created with a manifest header of:
Main-Class: Foo
The jar file would then be created:
jar cfm foobar.jar manifest.mf Foo.class
Upon execution, the -jar flag indicates that the manifest
header of foobar.jar specifies the class file containing the
"main" method:
java -jar foobar.jar
Under Windows32, the installation program registers a default association
of jar files, so that double clicking on the jar file will automatically
run it with the java -jar option.
Doclets
The javadoc tool has also seen significant changes in the move
to the Java 2 platform. The tool still generates API documentation from
doc comments placed in Java source code. But where the
javadoc output was once restricted to HTML, the new doclet API
facilitates a variety of text-file outputs--from HTML, to SGML, to XML,
to RTF, to MIF.
Doclets are simply programs written in the Java programming language which
use the doclet API to specify the content and format of the output produced
by the javadoc tool. They require use of the
com.sun.tools.doclets and com.sun.javadoc
packages.
The basic steps required to create and use a doclet are:
- The doclet program should import
com.sun.javadoc.*
in order to use the doclet API. The entry point of your program is a
class with a public static boolean start method that takes a
RootDoc as a parameter.
- Compile the doclet using javac in the Java Development Kit.
The doclet API classfiles are in the file
lib/tools.jar
in the JD7K software. Thus, include tools.jar in the
compiler's classpath:
javac -classpath C:\jdk1.2\lib\tools.jar ListClass.java
- To produce the output specified by the doclet, point to the
compiled doclet with javadoc's
-doclet tag. For
example, to run the doclet on a file called MyClass.java,
use the following command:
javadoc -doclet ListClass -classpath C:\jdk1.2\lib\tools.jar
MyClass.java
The output will be the string "MyClass".
Note that this command also requires tools.jar to be
in the classpath.
If javadoc is run without the -doclet
command-line option, it will default to the standard doclet and produce
HTML-format API documentation.
With the Java 2 platform, javadoc output no longer contains
default images (such as headings and bullets). In the old
javadoc, this created a great deal of confusion and manual
labor. The .gif files, necessary to any javadoc
output were located in the api/images directory. It was
previously necessary to manually create an images directory in the user's
javadoc destination directory and then copy the files to that
location.
And finally, several new @-commands have been added to the
javadoc API, including @link and
@throws, along with a change to @see such that it now accepts
packages, HTML anchors, and quoted strings (see the Resources links below
for further detail).
Conclusion
The above discussion is only the beginning in terms of the wealth of new
features and enhancements to be found in the Java 2 platform. Readers are
encouraged to more fully explore the areas of interest and relevance to
their specific environments. See Sun's
"Java
Development Kit Version 1.2 Summary of New Features" page for
greater detail. For formal training on the Java 2 platform, see the
Java
Developer Program by Sun's Java
University.
Steven Meloan is a writer, journalist, and former software developer.
His work has appeared in Wired, Rolling Stone, BUZZ, San Francisco
Examiner, ZDTV's "The Site," and American Cybercast's
"The Pyramid."
Contributions from:
- Todd Greanier, Senior Java Technology instructor for Sun's
Java University Developers Program.
- John Zukowski is a Software Mage with MageLang Institute.
He also serves as the Focus
on Java Guide at The Mining Co. and is the author of
Mastering Java 1.2, Java AWT Reference,
and Borland JBuilder: No Experience Required.
| 
Print-friendly Version
