 | |
As part of the process for defining the Java platform, Sun Microsystems pays a great deal of attention to customer and developer input and concerns. It has become clear that the JFC/Swing Package name is an item that people feel strongly about. The following is a proposal that has been carefully thought out after a great deal of input from developers, balancing the diverse needs of the larger Java community. 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.
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, the decision to use the "com.sun.java.swing" package name for JDK 1.2 has resulted in immense confusion in the developer world. It seems that many developers believe this naming compromises Swing's "core" status, as well as Sun's commitment to further the technology. This concern has been discussed widely on the news groups and Swing discussion aliases, and finally culminated into a JavaWorld poll. We've been listening intently to this feedback and have developed this proposal to name both packages "javax.swing" 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).
| |||||||
| |
| ||||||||||||
Print-friendly Version
