Prepare yourself for what's new and different in the forthcoming JDK 1.2 release

Core Java continues to grow and grow, but you'll be ready for the new release -- with JavaWorld's detailed analysis of all the additions

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

CLASSPATH settings

What's this? No more setting of CLASSPATH? No more 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 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, because that's standard when you run across a zip file.

To help alleviate this confusion, Sun made two big changes.

  1. The system class files no longer are specified by the CLASSPATH environment variable. Their location is, instead, specified automatically by the runtime environment. (Look up the sun.boot.class.path property or change it with -Xbootclasspath:paths/files.)

  2. 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 java.text.resources subpackage), and the jaws.jar file, which includes some other support classes (which provide capabilities including JavaScript integration with Netscape's JSObject, plus JSException classes and browser plug-in interoperability).

Extensions framework

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.

Just-in-time compilation

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 java.compiler to NONE. (The -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 FORCE_SIGNON.

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 -native and -green or the environment variable THREADS_FLAG.

Deprecated thread methods

With the 1.2 JDK, several methods of the Thread and 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 stop(), suspend(), and resume() in both classes, as well as countStackFrames() in Thread and allowThreadSuspension() in ThreadGroup.

The first three methods (stop(), suspend(), and 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 javakey, jar, and javadoc tools.

Security/signing tools

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 keytool and 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

The familiar 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 and 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, (or substitute whichever package you wish to document). An output sample for the SampleDoc doclet is also included in the Resources.

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

Audio enhancements

1 2 3 4 Page 1