November 1998


Mail this article
Printer-friendly version


More search options...
Search jCentral

Topical index
Net News Central
Developer Tools Guide
Book Catalog
Writers Guidelines
Privacy Policy


JavaWorld Partners

Software store

Sponsored by JW

Free e-mail alerts

JavaWorld Programs

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

The newest JDK release from Sun offers significant enhancements over earlier versions. From the addition of the Java 2D API to performance and stability enhancements to the pluggable VM architecture, John Zukowski's detailed analysis of changes and additions will get you up and running with JDK 1.2 in no time. (7,000 words)
By John Zukowski

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
First up is improved audio support, with no API changes. You can now play several different audio file formats, in addition to the familiar au files. With the help of a new sound engine in JDK 1.2, you can also play audio file formats of aiff, wav, rmf, and midi, too. This should reduce the need to convert Windows wav files to au format just to play them within Java programs. Also, there is finally support in the Core Java API for playing sound files in applications. No more digging into the package or creating a meaningless AppletContext; just call the new newAudioClip() method of Applet to get an AudioClip to play in an application.

File object enhancements
Developers will welcome the vast improvements to the File class. With JDK 1.2, most of the routines that used to return String objects to represent a filename (in JDK 1.1) will return another File that you can more easily work with. For instance, you can quickly sum up the size of the files in a directory with the following:

File aFile = new File (...);
long size=0;
File files[] = aFile.listFiles();
for (int i=0, n=files.length; i < n; i++)
  size += files[i].length();

Previously, you had to make sure you properly created a File for each filename returned from list():

File aFile = new File (...);
long size=0;
String files[] = aFile.list();
for (int i=0, n=files.length; i < n; i++)
  size += new File (aFile, files[i]).length();

The listFiles() method also accepts an optional FileFilter besides the FilenameFilter of list(). The two filters work the same, but the new FileFilter works with a File object, instead of the File and String of the FilenameFilter.

You can also now use the File class to create temporary files with createTempFile() and to create a simple file-locking protocol with createNewFile() and deleteOnExit(). In addition, you can easily convert a File object to a URL with toURL(), find out if an existing file is hidden with isHidden(), and make a file read-only with setReadOnly(). Note that the File class doesn't let you turn a read-only file into a writable file.

Number decoding
Expected in the FCS JDK 1.2 release, but not currently in the beta 4 release, are two parsing methods missing from earlier JDK versions. With methods like parseInt() in the Integer class and parseByte() in the Byte class, it seemed obvious to have parseFloat() and parseDouble() methods in the Float and Double classes, respectively. This omission should be corrected by the time JDK 1.2 is released, simplifying the procedure to something like:

float f = Float.parseFloat ("3.1415");
double d = Double.parseDouble ("2.718281");

The JDK 1.2 security enhancements are substantial. Steve Burnett, a crypto engineer at RSA Data Security Inc., thinks the Java Cryptography Architecture (JCA) 1.2 capabilities are a big improvement over 1.1: "The JDK 1.1 JCA had some deficiencies, making real-world applications using digital signatures difficult to write. With the new JCA, there are no more missing pieces. In addition to the cryptography, the new JCA offers certificate functionality. Many cryptographic applications rely on digital certificates to facilitate communication. Developers can call on the new cert library in the JCA to perform much of the needed functionality."

Besides the previously mentioned changes to command-line tools, the JDK 1.2 security architecture uses a permissions model for breaking out of the Java sandbox. Now, whenever you need to do a privileged operation, instead of signing code and enabling everything, you grant individual fine-grained permissions for specific operations. You use the policytool program to grant or refuse permissions based on data, such as who signed a given class and where it's loaded from. When it comes time to execute the privilege code block, the new access controller consults the policy database to see if the code has permissions.

In addition to the policy-based access control, JDK 1.2 includes many cryptographic services that go beyond the MessageDigest, Signature, and KeyPairGenerator capabilities of JDK 1.1. These include an X.509 version 3 implementation of a new Certificate interface, as well as additional support for managing the KeyStore and key factory support for converting between different key representations. Besides the JCA, there's a Java Cryptography Extension (JCE) available, which extends the 1.2 JDK to include more capabilities, like encryption. However, due to US export restrictions, it's not part of the JDK.

One interesting thing you can do in JDK 1.2 is set applications to run with the same security manager as applets. Simply set the System property from the command line and everything goes through the access controller.

java MyClass

JDBC 2.0
First introduced at JavaOne '98, the JDBC 2.0 API of JDK 1.2 greatly expands on the earlier JDBC capabilities. Probably the most important feature here is the ability to have true cursors when examining a result set, allowing you to move forward and backward and modify entries. The JDBC 2.0 API also is the first API to support the SQL3 datatypes to be adopted with the next SQL standard; these include blobs (Binary Large Objects), clobs (Character Large Objects), and user-defined datatypes (UDTs). Just remember not to mix up the java.sql.Array class with java.lang.reflect.Array.

To take advantage of the JDBC 2.0 capabilities, you must get new JDBC drivers. The older drivers will continue to work, but without the more advanced capabilities. Speaking of drivers, there happens to be an improved ODBC-JDBC driver with JDK 1.2, also.

Networking enhancements
As I reported in Java Tip 46: Use Java 1.2's Authenticator class (JavaWorld, February 1998), the networking classes have been improved to more easily support accessing password-protected URLs. Previously, in order to access password-protected URLs, you had to encode the Authorization property for the URLConnection. This has gotten much easier in JDK 1.2. The one change reported since February's Tip is a security-related modification. In the early beta versions of JDK 1.2, a password was placed in a String object and then passed along to the Authenticator. With the latest JDK 1.2 version, the password is now placed in a byte array. This allows you to clear out the password immediately after using it, instead of having to wait for the garbage collector to dispose of the password string.

Other new classes in the package include the following:

  • JarURLConnection class, which lets you access specific files within jar files with URL strings like jar:!/filename.txt

  • URLDecoder class, which complements the existing URLEncoder class

  • URLClassLoader, used for loading classes from URLs instead of files

Serialization enhancements/versioning
Serialization capabilities have evolved somewhat through the different beta releases. Assuming the beta 4 capabilities live on with the FCS version, the added functionality lets you customize serialization at a much lower level than previously possible. The magic happens within the two methods writeReplace() and readResolve(), which work somewhat like writeObject() and readObject(): if they exist they're called; if not, the default behavior is invoked.

In addition, JDK 1.2 boasts a new serialization protocol. If you're always serializing within one version of the JRE, this doesn't matter to you. However, if you have different clients with different versions of the JRE, things could get tricky. By default, JRE 1.2 writes with the new format, and JRE 1.1 environments write with the old protocol. Starting with JRE 1.1.6, both protocols are readable in JRE 1.1 environments. Also, both protocols are readable under JRE 1.2. If you wish to set a version to use when writing in JRE 1.2, you can call the ObjectOutputStream.useProtocolVersion() method.

Reflection enhancements
The improved JDK 1.2 reflection capabilities allow you to bypass access control checks when -- and only when -- using reflected methods. These allow capabilities like object persistence, debuggers, and other privileged tasks. By default, this option is disabled. You must specifically request that a class supports this, and changing it requires a pass through the security access controller, so untrusted beings cannot disable these capabilities unless they become trusted. To enable this option, you call the setAccessible() method of Field, Method, or Constructor, which is inherited from AccessibleObject.

AWT enhancements
User interface developers have focused on improvements offered by Swing, but let's not overlook changes within AWT proper. The most notable change relates to supporting internationalization efforts with a new ComponentOrientation class. A side effect of this class is the addition of new constants and behavior to the BorderLayout and FlowLayout layout managers. This affects programs only if left-to-right layout is inappropriate for your application's locale.

Additional AWT-related changes include the following:

  • A constant has been added to KeyEvent to support the euro (pan-European currency, to debut January '99)

  • A constructor that initializes all settings has been added to GridBagConstraints to ease IDE development with GridBagLayout

  • A setState() method that allows you to programmatically iconify and deiconify a frame has been added to Frame

JavaBeans enhancements
The JavaBeans enhancements in JDK 1.2 do not include Enterprise JavaBeans (EJB). EJB is a separate architecture that is not part of JDK 1.2. Sun defines 1.2 JavaBeans improvements as part of the Glasgow specification; they still aren't finalized. The drag and drop capabilities described below comprise one of the JavaBeans enhancements. The other new key JavaBeans capabilities come from the Runtime Containment and Services Protocol, which includes the classes in the java.beans.beancontext package. With this containment protocol, beans can more happily exist within other beans, and they're enabled to glean information about their surrounding environment. One thing that should be simplified is the interrogation and employment of available services from an environment (i.e., InfoBus). Also, you now load support files not only through the ClassLoader, but with the BeanContextSupport class, and JDK 1.2 provides better support for initializing beans as applets through the java.beans.AppletInitializer interface.

RMI enhancements
The 1.2 RMI enhancements are very handy. RMI with JDK 1.1 required the RMI server that generated the instance of the remote object to be running. RMI in JDK 1.2 allows these remote objects to be activated only when needed and suspended when not in use. This may reduce the memory requirements of servers considerably, as remote objects need only be active when necessary.

Standard library expansion
In addition to changes in existing libraries and classes, numerous new capabilities have been added to JDK 1.2. This has caused the number of standard packages shipping with JDK 1.2 to grow to more than 70 (versus the 23 packages in JDK 1.1).

The Core Java 1.2 packages finally add additional data structure support to the Java libraries, beyond arrays, vectors, and hashtables. Developers no longer have to look to ObjectSpace's Generic Collection Library for Java as the source of data collection classes. Sun's library represents a small, yet rich collection of about 25 classes that let you work easily with different groups of data, while somewhat hiding the underlying data structure implementation. (All the collection classes are found in the java.util package.) By default, accessing any of the new collection data structures is unsynchronized, unlike JDK 1.0 and 1.1. If you don't need synchronized access, you don't have to use it. However, when you must access something synchronized, you can do so easily with a call to a method of the Collections class. And, you can even make a collection read-only after you've stored everything in it, thus potentially boosting performance and security.

In addition to providing new generic data structures, Sun added support for performing tasks like sorting. You can now very easily sort an array with one easy call:

Arrays.sort (anArray);

In order for array sorting to work, there is only one requirement: the type of object in the array must implement the Comparable interface. All the key system classes with a natural ordering, like String, already implement the interface. For your own classes, you can either have them implement the Comparable interface, or you can define a separate class that acts as a Comparator to define your own ordering. Providing your own comparator works well when the default ordering is insufficient, i.e., for case-insensitive sorting of strings:

class CaseInsensitiveSort implements Comparator {
  public int compare (Object arg1, Object arg2) {
    String lc1 = arg1.toString().toLowerCase();
    String lc2 = arg2.toString().toLowerCase();
    return lc1.compareTo (lc2);

Then, to sort the array, just use the following:

Arrays.sort (anArray, new CaseInsensitiveSort());

The above functionality already exists in the Comparator stored in the String.CASE_INSENSITIVE_ORDER class variable.

JavaWorld contributor Dan Becker provides a detailed overview of the Java Collections framework in his article "Getting started with the Java Collections framework" in this month's issue of JavaWorld.

Weak references
JDK 1.2 adds the concept of reference objects to the set of tools developers can use to better manage memory. A reference object, or weak reference, is a reference to an object in memory. It has one catch though. The automatic garbage collector doesn't count this reference as a reference to the object. Thus, that object can be garbage-collected if no non-weak objects refer to it. The WeakHashMap collections class, introduced in beta 4, represents a hashtable where the keys are weak references. When the system needs more memory, the map size may shrink at will, with no notification to you. With phantom references, one type of weak reference, you can even perform post-finalization cleanup, after an object has been garbage collected. All this provides you with more direct control over storage reclamation strategies.

New in JDK 1.2 is an object request broker (ORB) to support interoperability between the Common Object Request Broker Architecture (CORBA) and a JRE, through Java IDL (Interface Definition Language). CORBA is similar to RMI for distributed object applications. But while RMI requires Java technology at both ends and a wire in the middle, CORBA has no such restriction and works between disparate computing languages and platforms. The CORBA support in JDK 1.2 makes future developments with Enterprise JavaBeans much easier, as CORBA is the most likely candidate for communication between Java environments and existing application services.

To use CORBA within a Java program, you create an IDL file that defines the interfaces to use for communication, similar to RMI. Then, after running this file through the idltojava command (available separately from the JDK), you get a set of classes that provide the stub and skeleton for communication. After defining your specific implementation, you're off and running. It really is very easy to use. And if you include CORBA services within an applet, you can take advantage of the ORB that comes with Netscape Communicator. One added command available to run your CORBA applications is the tnameserv program, which acts as a naming service, looking up service locations upon request.

Read more on Java 1.2's distributed object technologies in Bryan Morgan's "Java 1.2 extends Java's distributed object capabilities."

Thread local variables
JDK 1.2 adds support for static variables with different values based on which thread a class (or set of classes) is running in. These thread local variables work great for storing session identifiers and sharing them within a ThreadGroup. These types of variables are supported by the two classes ThreadLocal and InheritableThreadLocal, and are found in the java.lang package.

Version identification
With the package versioning support added to JDK 1.2, sometimes you can find out the name and version of packages. I say sometimes because a package isn't known to the system until a class is loaded from that package. So this doesn't look at all the packages in the CLASSPATH variable, just the loaded packages. For instance, the following three lines list all the packages known to a program:

Package p[] = Package.getPackages();
for (int i=0, n=p.length;i < n;i++)
  System.out.println (p[i]);

If you added a line like JButton jb = new JButton("Ack"); as the first line, the number of packages returned would expand significantly.

Versioning properties are set through the manifest file of the jar containing the classes. Currently, the Java Core packages do not provide version numbers, only names.

Floating point extension proposal
Two new keywords were added to JDK 1.2 with the beta 4 release: strictfp and widefp. These keywords let you specify the IEEE 754-standard strictness that a method or class uses when calculating intermediate results. Currently, these options are not used by the JVM, but you can place them in your code. The strictfp keyword acts like the current float behavior, while widefp is an extended-precision format, which may be faster. Here's how to flag a method to use the wide format:

widefp void doCalc (float x, float y) {...}

These keywords will not be added officially until the Proposal for Extension of Java Floating Point in JDK 1.2 is approved through Sun's Java standardization process. If rejected, the keywords will disappear, going the way of the private protected access modifier, which briefly appeared in a Java 1.0 release.

Java Foundation Classes
The Java Foundation Classes (JFC) encompass a large set of changes in JDK 1.2. JFC also includes the existing JDK 1.1.x Abstract Windowing Toolkit (AWT) capabilities. The 1.2 features of JFC are Swing, Drag and Drop, Accessibility, Java 2D, and the Input Method framework.

Swing is very likely the single JDK 1.2 addition that has received the most attention, probably because it's usable in JDK 1.1, too. Swing is a new set of Java components, providing a richer set of widgets than the original AWT controls. Instead of a small set of components that follow the lowest common denominator approach (if something isn't available on every Java runtime platform, it isn't available on any of them), the Swing component set is huge. By itself, Swing is larger than the original JDK 1.0. It offers everything from grid controls and labelled sliders to HTML rendering components, and more. The components are so flexible that you can change practically everything without changing anything. For instance, you can change the look and feel of your application without changing your event-handling code. You can even remove all event-handling code and deal with everything through the Model/View/Controller (MVC) architecture of the flexible Swing components.

In my experience, using the Swing components since last August has been a continual struggle. They tend to work best when doing everything by hand. While they were designed as JavaBean components, they were not initially created to be designable within drag and drop GUI environments like JBuilder or Visual Café. As the IDE vendors have improved their tools to be Swing-aware and Sun has improved the components to be more designable, we're now at a stage where Swing components are basically usable within second-generation IDE tools. Within IDE tools, however, you can only use the Swing components as replacement components for the AWT controls. You cannot use them, yet, in their more advanced MVC mode.

With all this flexibility of Swing comes complexity and performance bottlenecks. Performance has improved somewhat since the early days of Swing, but if it's to be a viable option for client-side applications, performance speed has to improve. Otherwise, we'll be forced to look to Microsoft's WFC (and limit our programs to run on only 90 percent of the desktop systems).

By the time JDK 1.2 is released, you'll find the Swing classes in the javax.swing package. This will be the third home for Swing in JDK 1.2; previously it lived in java.awt.swing and in

Undo/redo framework
The Swing classes (package javax.swing.undo) include a framework for supporting undoable and redoable activities. Whenever an editable activity occurs, you add it to the list of undoable activities an UndoManager is managing. Then, when a user asks to undo the activity, it can be undone. After being undone, it can also be redone, unless something isn't redoable, in which case a CannotRedoException is thrown.

Tomer Meshorer discusses Swing's undo/redo facility in "Add an undo/redo function to your Java apps with Swing" (JavaWorld, June 1998).

Drag and drop
The drag and drop capabilities of JDK 1.2 beta 4 are somewhat crippled. Not only has drag and drop changed significantly between beta 3 and beta 4, but Sun had to disable it completely under Solaris, permitting it to work only in Java programs on Win32 machines. Hopefully, by the time JDK 1.2 hits the street, all the kinks will be worked out, including that annoying three- to five-second delay before dragging is actually initiated.

Assuming everything is working, drag and drop is meant to permit dragging and dropping between Java applications and native platform applications. (See Resources for an example of using the beta 4 Drag and Drop API.)

The Accessibility API lets developers enable their applications for assistive technologies. These technologies include screen readers, voice recognition software, and many other options for users unable to physically see output or respond with input. Assistive technologies may be used to augment users with disabilities or support users whose jobs require them to be away from keyboard and monitor. The Swing component set automates many of the steps necessary to make components accessible. So, if you use them, there is little extra you need to do. However, you should still be aware of the capabilities and set appropriate messages when necessary (assuming an application could run in such an environment). Here's an example of how to set such a descriptive message. How it's used depends upon the assistive device installed.

  "Selecting this button turns off the coffee pot.");

Java 2D
The Java 2D API is an important part of the Java Foundation Classes. So important, in fact, that JavaWorld has columnist Bill Day writing about it in every issue (the JavaWorld Topical Index provides links to all of Bill's Java Media columns). The Java 2D API adds capabilities like adding an alpha (or transparency) channel to colors, drawing with antialiasing to get rid of the jaggies when drawing diagonal lines, filling shapes with arbitrary styles, and defining stroking patterns when drawing lines. I leave the details of the Java 2D API for Bill Day to explain.

Many people I spoke with placed the Java 2D capabilities among their top three enhancements in JDK 1.2, along with Swing and Security. "Component developers will be most interested in the 2D API provided in JDK 1.2, which eliminates the complicated and slow capabilities introduced in JDK 1.0," says Frank Pittelli, PhD, of Pittelli & Associates, co-founder of ChartWorks Inc. (formerly NetFactory), a Java-based charting solution provider. "As the designer of charting components, I only wish that the 2D API was around three years ago, when it all began."

Input Method framework
The Input Method framework supports input of multibyte characters (specifically Japanese, Chinese, and Korean) within text components. Currently, the TextArea and TextField components of AWT cannot support this framework because they use the underlying operating system to create the controls through platform-specific peers. If you need to use this framework, you must use lightweight components, like the Swing controls.

Printing in JDK 1.2 now supports an optional print dialog. JDK 1.1 printing capabilities required a print dialog, so you couldn't automate print jobs for after hours. Located in the java.awt.print package, the key class for printing is PrinterJob and the key interface is Printable. The print() method of the Printable interface is repeatedly called as long as the method returns Printable.PAGE_EXISTS. The calls cease when the method returns Printable.NO_SUCH_PAGE.

Font support
You can forget about the limited font support in JDK 1.0 and JDK 1.1. With JDK 1.2 you now have access to all the fonts available on your system (or at least those available by the directory specified in the JAVA_FONTS environment variable). Instead of asking a Toolkit for the font list, you ask the GraphicsEnvironment. You then set the font according to the user's choice.

GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
Font fonts[] = ge.getAllFonts();
Font aFont = fonts[1].deriveFont (Font.PLAIN, 12);
// or
String fontList[] = ge.getAvailableFontFamilyNames();
Font bFont = new Font (fontList[1], Font.PLAIN, 12);

Buffered image
With the addition of the java.awt.image.BufferedImage class, double buffering has gotten much easier. No longer do you have to worry about when createImage() will return a valid Image object. And, you can specify the bit-depth when you create a buffered image, or ask for the optimum image format for the current graphics-display configuration.

BufferedImage biOne =
  new BufferedImage (640, 480, BufferedImage.TYPE_INT_RGB);
// or
Graphics2D gwd = (Graphics2D)g; // g is arg to paint()
GraphicsConfiguration gc =
BufferedImage biTwo =
  gc.createCompatibleImage (640, 480);

Unfortunate incompatibilities
Sun's Java Development Kit Compatibility with Previous Releases page (see Resources) contains a complete set of version incompatibilities. Unfortunately, there are some. Most of the incompatibilities listed are the result of bug fixes. However, there are some that aren't related to bug fixes. They're caused by the addition of classes, where a new class is given the same name as an old one, but exists in a different package. You may happen to import both into your program, due to importing with asterisks (that is, import java.util.*), in which case you'll have to explicitly import one in the source before it will successfully recompile (or explicitly reference the class name). The most frequently used duplicately named classes are as follows:

  • java.lang.reflect.Array/java.sql.Array
  • java.sql.Date/java.util.Date
  • java.awt.List/java.util.List
  • javax.swing.filechooser.FileFilter/

JPEG encoding
The com.sun.image.codec.jpeg package comes with Sun's JRE and allows you to read and write JPEG files. While reading has long been available with getImage(), writing previously required a third-party package, assuming you wanted to maintain the JPEG encoding when you saved. When first introduced into an early beta version of JDK 1.2, these classes were in a different package, under the java.* hierarchy. After causing quite a bit of controversy, they were moved. They're not considered part of the Core API. However, they are available with the runtime environments provided by Sun.

FileInputStream fis = new FileInputStream ("imagefile.jpg");
JPEGImageDecoder decoder = JPEGCodec.createJPEGDecoder (fis);
BufferedImage bi = decoder.deco deAsBufferedImage();

Once you've read the file into a buffered image, you can manipulate it, and later save it back out. Saving allows you to set JPEGEncoderParam data like image quality, or you can just use the defaults, as follows:

FileOutputStream fos = new FileOutputStream ("imagefile.jpg");
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder (fois);
encoder.encode (bi);

What happened to servlets?
When JDK 1.2 was first announced, the servlets package (javax.servlet) was supposed to be included as a standard extension with the 1.2 development and runtime environments. At some point, Sun decided it was best left packaged separately, in the Java Servlet Development Kit (JSDK). The 2.0 JSDK is the latest release, and works with both JDK 1.1 and JDK 1.2. When creating servlets, be sure to use the version of Java technology supported by your servlet-enabled Web server. The only deprecation change between the 1.x and 2.x servlet packages is the getServlets() method of ServletContext, which has been deprecated in favor of the getServletNames() and getServlet() methods.

If you've been using the 1.x JSDK, the biggest changes you'll see in the move to the 2.x JSDK include delegation of different request types to specific methods (like doGet and doPut) of HttpServlet, the addition of Reader and Writer support with ServletRequest and ServletResponse, as well as the addition of the SingleThreadModel interface to indicate a servlet should implement service requests in a single-threaded manner.

Browser support
For now, browser support for JRE 1.2 will be provided with Sun's Java Plug-in. This immediately enables JRE 1.2 within Netscape Navigator 3.0/4.0 under Windows (NT/95/98) or Solaris (SPARC and x86 (3.0 only for x86)), as well as Internet Explorer under Windows (4.0 for NT/95/98 and 3.02 for NT and 95). Until the Sun vs. Microsoft Java lawsuit has been resolved, you shouldn't expect to find JRE 1.2 support in Internet Explorer directly from Microsoft. As far as Netscape goes, rumor has it that the company plans to include the Plug-in with a future release of its browser software, instead of requiring the separate installation of the tool.

With the JDK 1.2 FCS release soon upon us, there is much to learn if you wish to stay current with the third generation of Java technology development. This article highlights key areas you'll want to continue exploring on your own. The good news is that, with the sole exception of security-related code, everything should recompile and run fine under the 1.2 environment. Hopefully, 1.2 will run faster than, or initially at least as fast as, JDK 1.1. While Sun has delayed the FCS for some time now, it appears JDK 1.2 will serve as a complete development environment with a polished API set. Rick Ross, president of Java Lobby, commented that Sun "has to fix today's problems before adding more improvements" and said Sun was "right to hold off delivery of JDK 1.2 to achieve a lower-memory footprint and better performance." Ross said performance is key, "particularly for people creating applications competing with natively compiled code." Hopefully, by the time JDK 1.2 comes out, with capabilities like a feature-complete Swing implementation and better performance, Java developers will be happy. JDK 1.2 offers many new features, and if Sun can keep to its promised numbers, Frank Pittelli claims, "Java 1.2 will achieve wide scale acceptance and will be able to serve as the basis for millions of development projects over the next few years."

Sign up for FREE E-mail Alerts & get weekly updates

About the author
John Zukowski John Zukowski is a software mage with MageLang Institute, author of Mastering Java 1.2, Java AWT Reference, and Borland's JBuilder: No experience required, as well as the Focus on Java guide at The Mining Co.

Tell us what you
thought of this story

-Very worth reading
-Worth reading
-Not worth reading

-Too long
-Just right
-Too short

-Too technical
-Just right
-Not technical enough



Company Name:



Advertisement: Support JavaWorld, click here!

(c) Copyright 1998 Web Publishing Inc., an IDG Communications company

Technical difficulties:
Last modified: Thursday, July 01, 1999