Execution and Configuration

Also, the classes.zip file has been eliminated, and the associated use of the classpath has significantly changed.

Classpath Background

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

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

(The properties below can only be examined from a trusted program.)

1. 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").

2. 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").

3. 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

                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

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 threads option can either be set using command line options:

java -native myapp

java -green myapp

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

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

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:

1. 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.

2. Compile the doclet using javac in the Java Development Kit. The doclet API classfiles are in the file lib/tools.jar in the JDK software. Thus, include tools.jar in the compiler's classpath:

   javac -classpath C:\jdk1.2\lib\tools.jar ListClass.java

3. 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.