Archived March 1998

Why There Are Two Swing Packages

By Tom Ball

There’s been some discussion about why JavaSoft’s Swing team is distributing two different packages. It seems like a waste of bandwidth to have the same code bundled twice, and i

t seems to put an unfair burden on Swing developers.

Because I’m the one who came up with this scheme, I have written this commentary to let you know why it was necessary and to dispel many of the misunderstandings which have been posted to Swing interest groups.

Swing has two seemingly contradictory marketing requirements: It must run on 1.1 and be downloadable to 1.1 browsers, and it must be part of the 1.2 core (java.*) classes. The first requirement was established because developers want to deploy Swing applications right now, rather than waiting for browsers and other VMs to support 1.2. (Our team really appreciates this show of confidence in our project -- thank you.) For a class to be downloadable in today’s browsers, it can’t be in either the java.* or sun.* class hierarchies, so we chose com.sun.java.swing, as recommended by the JLS.

We also distribute Swing as a set of JAR files so that they can be downloaded as part of an applet. We’re still resolving problems here due both to bugs in our code and browser incompatibilities, but we’re getting closer each day (keep sending those bugs in to swing-feedback -- we’re tracking them all).

Why Swing needs to be in core

Swing needs to be in core in 1.2 for several reasons, some marketing and some technical. JavaSoft believes that over time, more and more Java GUI development will be done using Swing -- not because we’re forcing anyone, but because lots of developers have told us they will. Swing seems to be much closer to what they need than the AWT, and can be more easily enhanced and quickly maintained than the AWT.

Although we’ll continue to be supportive of other GUI frameworks, we realized that there needed to be a GUI framework (not necessarily the framework) in core so there’s a minimum all GUI developers can rely on. Being in core requires that classes be in the java.* hierarchy -- no way to wiggle around that requirement.

From a technical perspective, having Swing in core gives the AWT team a chance to start using Swing facilities in the future as appropriate, and to eliminate redundancy between the two packages over time. This won’t change the AWT’s API, but it has the potential to improve its quality by reducing unnecessary platform-specific code. Our tools group is also interested in using Swing as well. (So for once, product marketing and development engineering agree on something.)

Another marketing requirement

A third product marketing requirement -- and something that is just assumed by our clients -- is that Swing will be integrated appropriately with the rest of 1.2. It should, of course, support drag-and-drop and Java2D, and JTable should support the new collections API. This requirement runs smack into the "runs on 1.1" requirement, however, as supporting the 1.2 functionality requires make 1.2 API calls.

Some of that can be worked around by dynamic loading 1.1 classes instead of 1.2 classes, but that isn’t always possible. We’ve heard complaints that we are shipping two duplicate bundles (with changed package names), and while that’s true today, it won’t be as soon as we start integrating with the rest of 1.2.

Why aren’t we using the javax.* extensions facility? We considered that, but encountered two problems It would make Swing always optional (the AWT and other core packages can’t rely on it), and it would prevent different implementations of Swing for 1.1 and 1.2 -- which would mean that we’d have to stick with only 1.1 support. Our customers have told us that this would be unacceptable.

What it all means to developers

So what does all this mean when you want to develop and deploy a Swing app or applet?

It’s a simple choice: . Use com.sun.java.* if you want to run with 1.1-compatible browsers and VMs, and bundle Swing’s JAR files with your app or reference them in your applet HTML tag. Your app will continue to work in 1.2 (separate class-loading), although it won’t take advantage of any 1.2-specific features. Use java.awt.swing.* if you want to run with 1.2-compatible browsers and VMs, and don’t bother bundling Swing’s JAR files.

To convert between the two packages, we use a stream editor (sed, available on Win32, UNIX and Linux platforms) as part of our build -- once you change your makefiles, it’s painless.

I hope this answers your questions regarding Swing packaging.

[an error occurred while processing this directive]