Soon, Sun Microsystems will be releasing the FCS (first customer ship) version of JDK 1.2 for Windows NT 4.0, Windows 95/98, and Sun Solaris 2.5.1/2.6 for both Intel x86 and SPARC. This is the first non-beta version of the 1.2 Java Development Kit (JDK) and Java Runtime Environment (JRE). According to Gina Centoni, group manager for the Java Platform at Sun, "the release is scheduled for the end of November."
With this release of the JDK comes a slew of changes that should keep Java technology developers, book authors, and trainers (not to mention Java technology magazine authors and editors) busy upgrading our knowledge sets, books, and training materials (and articles) for some time to come. While some pieces of the new version (most notably Swing) have been available for more than a year now, significant changes have crept into the latest beta version of the software, 1.2 beta 4. We'll bring you up to speed with these changes now, so you'll be ready to make the most of them when JDK 1.2 hits the street.
And, if the hype is true, this is one package you'll want to be prepared for. "JDK 1.2 is the most significant delivery of Java technology thus far," Centoni says. "Based on customer feedback, it provides a completed platform that includes essential features for development of solutions in the Enterprise." According to Dr.Simon Moores, president of The Java Forum, "The new 1.2 features represent an evolutionary step from a cool programming language to a serious preparatory technology, capable of supporting the wired infrastructure of the early twenty-first century."
Centoni specified several key features that contribute to the merit of JDK 1.2:
- The addition of the Java 2D API
- Significant enhancements to the security model
- The pluggable VM architecture that will support the HotSpot VM
- Advancements to the Java Foundation Classes
- Enhancements designed to improve performance and stability
The changes offered in the 1.2 JDK fit into about four categories. We'll look into each of these categories in some detail, demonstrate the new capabilities, and prepare you to take advantage of them.
- Development and runtime environment changes
- Standard tool changes
- Standard library enhancements
- Standard library expansion
We'll also look at a number of non-Core Java packages, and point out JDK 1.1/JDK 1.2 compatibility issues you should be aware of.
Development and runtime environment changes
Developers will run across the first set of changes quickly. The basic environment configuration has changed. Most of the worry related to modifying the
CLASSPATH environment variable is gone, both for development and runtime (end-user) environments. And you can forget about the classes.zip file that stored all the Java class files. That, too, is gone. The
jre command also is gone, as it was just an alternate way of starting something with
What's this? No more setting of
CLASSPATH? No more classes.zip file? Here's the scoop: With JDK 1.1, initial installation required you to add the bin directory under the JDK installation directory to your
PATH environment variable. That isn't a problem and hasn't changed with JDK 1.2, assuming you want the compiler and other tools in your path. It's the next step that's changed.
With JDK 1.1, if you wanted to expand upon the core set of libraries the JDK had available to you at compile time or runtime, you had to worry about the
CLASSPATH environment variable. When unset, the default variable setting contained the classes.zip file from the JDK distribution and a period (.) to signify the current directory as the location of class files. As long as you didn't need to add packages of classes to your toolkit, you didn't need to make any changes. But as soon as you needed to add one new location you had to set the
CLASSPATH and remember to include the default settings. This caused much confusion, as you couldn't simply append something to the old setting. Also, some people thought they needed to unzip classes.zip, because that's standard when you run across a zip file.
To help alleviate this confusion, Sun made two big changes.
The system class files no longer are specified by the
CLASSPATHenvironment variable. Their location is, instead, specified automatically by the runtime environment. (Look up the
sun.boot.class.pathproperty or change it with
- The system classes no longer reside in a zip file. They're now in Java Archive (jar) files. The runtime classes are now found in the file rt.jar in the jre/lib directory, while the JDK-support tool classes are found in the tools.jar file in the lib directory. The other two jar files that ship with the JDK are the i18n.jar file, which includes internationalization support classes (like in the
JSExceptionclasses and browser plug-in interoperability).
While JDK 1.2 clears up the configuration of
CLASSPATH for the system classes, it also eliminates the need to add anything else to the
CLASSPATH. How this happens is based on the new Java Extensions Framework, introduced with JDK 1.2. Just place a jar file in the lib/ext directory, under the Java runtime directory (specifically jre/lib/ext with the JRE), and you've just installed the library. No more setting the
CLASSPATH. If you don't want to place classes in a jar file, you can place them in the classes directory (also under the Java runtime directory (specifically jre/classes), although it's nonexistent by default).
The second part of the extension framework is for downloadable extensions. If you wish to use a library within an applet, you can place a special
Class-Path: line in the manifest file of the applet's jar file. This addition eliminates the need to either manage one huge jar file for the applet or specify multiple jar files with an
<APPLET> tag. Such changes should make the support staff's job much easier when your development efforts move to the deliverable stage.
Of course, if you still want to, you can use
CLASSPATH for adding non-system libraries and specify multiple jar files with the
<APPLET> tag. It just isn't necessary.
To help speed up performance, Sun's JREs come with a just-in-time (JIT) compiler for both Windows and Solaris. By default, each is enabled and should speed performance considerably, depending on your application. To disable the JIT, set the System property
-nojit option is no longer valid.) Disabling allows you to see source code line numbers when an unexpected exception is thrown. To find out which version of the JIT compiler you're using, set the
JAVA_COMPCMD environment variable to
Native threads in Solaris
Prior to JDK 1.2, Java technology users on multiprocessor Solaris boxes couldn't take advantage of the multiple processors within a single Java program. Now, with the addition of native-thread support, you can use either the original (and still default) "green" threads or the newer native threads. Set your threads choice with the command-line options
-green or the environment variable
Deprecated thread methods
With the 1.2 JDK, several methods of the
ThreadGroup classes have become deprecated. This means they should be avoided. (In fact, they should have been avoided starting with the 1.0 JDK, but their use was sometimes necessary with JDK 1.0 because
interrupt() didn't function properly.) The deprecated methods are
resume() in both classes, as well as
The first three methods (
resume()) should be avoided because they aren't safe. They have a tendency to either leave objects in an improper state, for example when
stop() is called at a bad time, or leave a system in a deadlocked state, for example when
suspend() holds an object with an unreleased lock. If you happen to be using these methods now, Sun's online Java tutorial describes how best to update your designs.
In addition to the previously mentioned runtime environment changes, developers (and users) will notice several areas of performance enhancements for behind-the-scenes activities. Locks for synchronization will occur much faster with monitor speedups, speed of memory allocation and garbage collection has been improved, and loaded classes will boast a smaller footprint (based on memory compression due to the sharing of constant strings across class files). According to Patrick Vermont, director of Apptivity product management at Progress Software, "Anything and everything to improve performance is critically important for Java adoption to continue. Performance improvements from both the [pending] HotSpot compiler and the new garbage collection algorithms are extremely welcome. It feels like Sun is really investing in making 1.2 a solid platform. [This is] important for Java to spread up into large organizations and to be used for mission-critical applications."
One handy thing that may no longer be in place when JDK 1.2 is finally released is support for the
_JAVA_LAUNCHER_DEBUG environment variable. When set, this causes your Java runtime environment to generate numerous debug messages at startup, which is a big help in the resolution of configuration problems.
Standard tool changes
Now that you've seen some of the basic environment changes and performance improvements, let's start digging into real development-related changes. In the area of tools, there are three primary changes. These are related to the JDK 1.1
In the 1.1 JDK, all security-related code-signing tasks (including key and certificate management) rely on the
javakey tool. In the 1.2 JDK, this single overworked tool has been replaced by two, and a third tool supports a new JDK 1.2 security capability. The upshot: First, your key database from JDK 1.1 has been renamed keystore and moved to the user's home directory, and the original file is no longer valid. Second, the JDK 1.2 key database is now password protected. The basic process of signing code remains the same, except you now use
jarsigner where just
javakey was used before. The third tool,
policytool, actually has a graphical interface, unlike almost all the other tools. The
policytool supports JDK 1.2's new policy-based access-control capabilities. We'll talk about these more below.
New jar command options
jar command, used to create jar files, has two added command-line options. Many developers have been eagerly awaiting the first option -- an update feature. The
-u option allows you to either add or replace files to a pre-existing jar, so you no longer need to re-create the entire jar file from scratch. For example, to update just the Sugar.class file in the cookie.jar file, you would enter the following command:
jar uf cookie.jar Sugar.class
The second new jar command option,
-C, lets you change directories as you're creating (or updating) a jar file. For instance, if you want to jar files from three different directories, you can either copy everything into one target directory and jar everything, or leave everything where it is and jar the pieces together, as shown here:
jar cf cookie.jar -C first first/*.class -C ../second second/*.class -C ../third third/*.class
The third tool seeing significant changes in the move to JDK 1.2 is
javadoc. The command still just generates API documentation. The differences lie in the default output format and how it goes about generating the output. First, the output no longer contains images, so you don't have to constantly copy the images subdirectory over from another set of output. Second, if you don't like the output, you can create a program called a
doclet to reformat the output. This requires the use of the
com.sun.javadoc packages to customize output. Once you've created your
doclet, you use it with the new
-doclet option of
javadoc. For instance, you can automatically generate your own copy of Java in a Nutshell-like appendices for any set of Java source files. Try the sample
doclet included in the Resources section below. Be sure to run it from the root directory in which you unjarred the src.jar file that comes with the JDK. Just compile the source and execute the following command:
javadoc -doclet SampleDoc java.net, (or substitute whichever package you wish to document). An output sample for the
SampleDoc doclet is also included in the Resources.
javadoc change has to do with the directory structure created for the output files. Instead of one huge directory of all output files, the different packages are each placed in their own tree. There are many other
@-commands added, too. See the
javadoc enhancement link in the Resources.
Standard library enhancements
Now that we've seen what's new and different with the various tools, let's start looking at what's different with the existing classes. There are at least 11 different areas where the capabilities of the existing Core classes have changed.