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

1 2 3 4 Page 2
Page 2 of 4

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 sun.audio 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");

Security/policies

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 java.security.manager System property from the command line and everything goes through the access controller.

java -Djava.security.manager 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 java.net package include the following:

  • JarURLConnection class, which lets you access specific files within jar files with URL strings like jar:http://www.javaworld.com/aJar.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).

Collections/sorting

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

1 2 3 4 Page 2
Page 2 of 4