Swing Packaging

A Naming Dilemma and a Proposed Solution

The components in the Swing set have a dual role: They are part of the 1.2 JDK set of core classes, but they can also be referenced by applets running on JDK 1.1-compatible browsers. When these two features of Swing components come up against applet security restrictions, they present three mutually contradictory requirements to the people who must come up a package name for Swing:

They must be part of the set of Java core classes, so the Swing classes must be part of the java.* class hierarchy.
However, the Swing classes cannot be part of either the java.* or sun.* class hierarchies because classes from these hierarchies should never be downloaded by browsers.
Finally, applications written for a 1.1-compatible environment must run unchanged on a 1.2-compatible environment.

Solving the Puzzle: A Proposal

To the best of our knowledge, there's no way to satisfy these requirements with a single set of Java classes. Consequently, this proposal describes a set of thin wrapper classes and an overall packaging strategy for Swing.

Package Names

To solve the package-naming puzzle, the proposal recommends the use of two packages for Swing: one named com.sun.java.swing and one named java.swing. The com.sun.java.swing package will be used for applications and applets that need to run on version 1.1 or later Java systems. The java.swing package will be used for applications that are designed to run on version 1.2 or later systems.

NOTE: There have been questions about the use of the letters "com" in package names instead of "COM", as defined in the Java Language Specification. To resolve these questions, the JavaSoft division of Sun Microsystems Inc. has determined that the JLS will be updated to recommend the use of "com", and that is why this proposal uses it. Starting with JDK 1.2, non-core packages from Sun Microsystems will be prefaced with "com.sun" . (The use of the word "java" in "com.sun.java.swing" does not follow Sun's new conventions, but this proposal recommends that it be used to show the linkage between the two packages.)

Swing JDK Build

The JDK build is responsible for building both the java.swing and the com.sun.java.swing classes. For the 1.2 JDK beta, the Swing source files will be checked into the appropriate place in the 1.2 JDK source base. To build 1.2-compatible classes, an extra build step will be added which copies each source file to a separate source area and replaces all "com.sun.java.swing" references with "java.swing". After compilation, these converted source files will be archived into the JDK source ZIP file which is included with the distribution. These converted source files should never be edited or checked back into the JDK source base.

Expected Questions

This section presents some anticipated questions, and answers them.

What happens if an applet which bundles the 1.1 version of Swing is run on a 1.2 system?

The applet will continue to use the 1.1 version. From a classloader's perspective the classes in 1.1 and 1.2 are completely different, even if the code is the same.

Is there anyway to be 1.1-compatible and avoid downloading the 1.1 Swing JAR file?

Existing methods for downloading third-party code, such as adding the Swing JAR file to the local classpath or using Marimba's Castinet can be used. The 1.1-compatible version of Swing is, for all intents and purposes, a third-party component suite just like the ones that are currently available.

How can Swing bug fixes made to the 1.2 JDK be made available to 1.1 customers?

When 1.2 JDK maintenance releases are built, a new revision of the 1.1-compatible JAR file also needs to be built and distributed with the 1.2 JDK. It is the responsibility of application and applet distributors who are using the 1.1-compatible Swing JAR file to update their distributions.