|
Archived
March 1998
Why
There Are 2 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 it 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.
| |
|
|
|
This page was updated at 4 p.m. PST
on Tuesday, March 16, 1999
|
For information,
call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's
AT&T Direct
Access Number first. |
|
|