Swing is, and continues to be, a core package of JDK 1.2 and an
unbundled library for running on JDK 1.1. This presents an
interesting challenge in naming the package. Two major
concerns arise:
Proposal
We propose to place Swing in the package name
"javax.swing". This package name will be used for Swing 1.1 (for JDK
1.1) and for the core package in JDK 1.2. The "javax" prefix indicates
that this is a package that was initially developed as an "extension"
(for JDK 1.1), and has migrated into the "core" runtime for JDK 1.2.
As other extensions migrate into core, they will also retain their
"javax" prefix.
We sincerely hope that this addresses the needs of the largest portion
of the community.
Please e-mail us before Friday, August 28th, at
swing-comments@eng.sun.com
and let us know whether we are doing
the right thing.
As always, we really do appreciate all of your
feedback.
Thank you.
The Swing! Team
Background
Since then, many developers have adopted Swing and have been shipping
applications for JDK 1.1 (using the "com.sun.java.swing" package name).
Once JDK 1.2 beta 3 was released (with the "java.awt.swing" package name
change), many of these developers contacted us to convey how difficult
it was to maintain source code and binaries for each JDK version. In
particular, the tools developers were burdened not only with managing
the development of two source bases, but also in trying to provide a
tool which supported the development of Swing programs for each JDK
version.
In response to this feedback, we announced for JDK 1.2 beta 4 that we
were placing Swing in "com.sun.java.swing" for both the external
JDK 1.1-based package and the core package for JDK 1.2. We believed
that this would ease the lives of our developers because it would mean
that existing Swing binaries would run unchanged in JDK 1.2, and that
separate source bases would no longer need to be maintained by our
developers.
Long before making this beta 4 package name decision for Swing, Sun
realized that the process of migrating external packages into core would
likely require package names other than "java." to be present in core.
Therefore, we understood clearly that this decision in no way impacted
Swing's "core" status in JDK 1.2.
However," in order to address
the negative concerns over the "com.sun.java.swing" name. We believe
this solution balances the needs of both camps of developers.
In fact, had the standard-extensions mechanism existed in the Spring
of `97, "javax.swing" would have been the plan of record from the beginning.
Frequently Asked Questions (FAQ)
Why "javax.swing"?
When we announced that Swing would be in "com.sun.java.swing" in JDK1.2 we received a lot of very valuable feedback from developers. Many developers were concerned about having a "com.*" package in core and having a company name reflected in a core package.
Further feedback showed that "com.sun.java.swing" did not indicate clearly enough that Swing is a core package in JDK1.2. Also based on developer feedback, it is very important to have one package name for both Swing 1.1 for JDK 1.1 and for the Swing package core to JDK1.2.
We feel "javax.swing" is the solution which best addresses all these concerns.
What is this "javax" name space?
The "javax.*" namespace is reserved for Standard Extensions. Examples of other Standard Extensions are "javax.infobus" and "javax.mail". Currently Swing is an external package to JDK 1.1, and thus in the context of JDK 1.1, Swing can be referred to as a Standard Extension.
A Standard Extension to a certain reference release of the JDK that is designated core for a next reference release of the JDK will retain its "javax.standardextension" package name. If, for example, InfoBus were to move into core in a future release of the JDK, InfoBus will retain the "javax.infobus" package name.
Why another change in the naming?
Developer feedback convinced us that the "com.sun.java.swing" naming scheme was not the best path forward.
Why not "com.sun.java.swing" for JDK 1.1 and "java.awt.swing" for JDK 1.2?
For developers building programs for both 1.1 and 1.2, maintaining source and binaries for two package names is extremely difficult. This also makes it difficult for tools vendors to provide great Swing support in their tools for developers.
Why can't a simple conversion tool be provided to ease the transition from "com.sun.java.swing" to "java.awt.swing"?
The issue is not so much the "one time" conversion cost (we've already shipped such a tool with early access versions of Swing to help with migration of API changes in the early days), but the on-going cost of maintaining two source bases and binaries. Most of the developers who attempted this with JDK 1.2 beta3 sent us strong feedback that this not a feasible development scenario for building products.
Why no package aliasing in JDK 1.2?
Our VM/language team investigated this closely. Although at first hand this appears simple, detailed evaluation shows it is a very complex issue.
Package aliasing would require non-trivial changes to the JVM (including changes to the byte code verifier to understand dependencies and aliases). The implementation of classloaders would have to change (for example, making sure that both the VM classloader and the URLClassloader can locate and understand a package alias is non-trivial). And finally, the reflection API makes it extremely difficult to guarantee a package aliasing mechanism would work compatibly with existing programs.
Why not "java.awt.swing" or "java.swing" for both JDK 1.1 and JDK 1.2?
Unfortunately, giving a "java." prefix to the JDK 1.1 product would prevent it from being downloaded into some browser environments.
Does the "javax.swing" package name mean Swing is not core?
On the contrary, Swing is and continues to be a core package of JDK1.2 and future reference releases. It should be considered a package that was originally developed as an extension, but has moved into core.
How will developers know Swing is core if it does not have the "java." prefix?
The list of "core" packages for a particular JDK release will be clearly documented in the release documentation. We will also document that the Swing classes are "core" in JDK 1.2 in the javadoc for Swing (for the many developers who may not read the general release documentation).
Doesn't this mean that everyone will have to convert their source code (rather than just JDK 1.2 developers)?
Developers using JDK 1.2 or JDK 1.1 will need to convert their sources/class files. We will be providing a tool to ease this one-time transition cost. However, once the source code is converted, a single copy can be used with both Swing1.1 or JDK 1.2.
JDK 1.1 developers who are not currently in a position to convert can continue to use Swing1.0.3 (which still has the "com.sun.java.swing" package name).