Developers say Sun should keep its Swing package promise for JDK 1.2

Find out where JavaWorld readers want Sun to house JDK's GUI component set

When JavaWorld followed the suggestion of several readers to run a poll in early August asking "Where would you like to see Swing packaged for use with JDK 1.2?" we thought it would generate lots of attention. But the number of votes and comments we've received over the past two weeks exceeded even our less-than-modest expectations. The packaging of Swing -- the broad set of GUI components at the heart of Sun's Java Foundation Classes software (JFC) -- is definitely a hot topic among Java developers.

Three out of four respondents (76%) said they want Swing to reside where Sun originally intended: java.awt.swing. Roughly one out of seven (15%) preferred that Swing remain in its current place, com.sun.java.swing. Other respondents suggested alternative homes, such as java.swing, javax.swing, java.jfc.swing, or jfc.swing.

As stated in the background of the poll, Sun says its decision to house Swing in com.sun.java.swing benefits developers who have already developed, or are developing, products using JDK 1.1. It will also simplify the migration of products to a JDK 1.2 code base. (JDK 1.1-compatible browsers cannot download classes from the java.* package hierarchy, due to security issues.)

Sun also says, "Swing is core to JDK 1.2."

"The package name does not define what's core," explains Onno Kluyt, Sun senior product manager for JFC. Though he agrees that, in principle, core components should reside in the java.* hierarchy, Kluyt contends that in some cases -- like Swing, or the CORBA package (org.omg.corba) which is also considered core by Sun -- it may be better to put components outside the java.* hierarchy for reasons such as "compatibility with existing solutions" and the need to retain an "association with an industry standard."

"Swing has been part of the core design of JDK 1.2 right from the start, notes Kluyt. "The Swing implementation was ready before JDK 1.2 would be available. So at the time we decided to make Swing available for JDK 1.1 environments in the com.sun.awt.swing package and announced that the package would be in java.awt.swing for JDK 1.2. This was reflected in JDK 1.2 Beta 3.

"Our main objective with the current naming scheme (com.sun.java.swing for core and unbundled versions of Swing) is for the package name to be identical in both cases," Kluyt said. "javax.swing and java.swing would create a third-name candidate for the Swing package and force everybody to migrate. Additionally, the javax.* namespace is reserved for standard extensions. Putting Swing, a core package, in that namespace would create confusion [about] whether Swing is core and whether or not standard extensions like InfoBus and JAF are core."

Kluyt says that Java licensees must adhere to Sun's definition of core, which is not inherently limited to java.* components. He says many people may have based their votes in part on confusion about the definition of core, and acknowledges that Sun must better educate the Java community about this important distinction. "We need to [explain] what core means. I don't think this package name [com.sun.java.swing] necessarily increases the risk of incompatibilities on the platforms."

Apparently, education indeed is in order, and should extend not only to licensees and the Java developer community, but to Sun's own staff. Even Tom Ball, a veteran Java engineer at Sun, recently wrote in a commentary about Swing packages that "Being in core requires that classes be in the java.* hierarchy -- no way to wiggle around that requirement."

(Ball now says that when he wrote his March commentary, his understanding of core was based on a false assumption shared by the rest of Engineering. "It didn't actually jibe with what the lawyers have been putting in all the contracts ... Onno is right." )

Kluyt says Sun based its current position on input from developers. Sun continues to look at the feedback and wants "to make sure we do what's best for the Java community," he says. "We always have and continue to really value the sentiments [of developers]." Readers who did not provide comments via the JavaWorld poll may submit their suggestions regarding Swing to swing-feedback@java.sun.com.

Poll details

More than 2,500 developers took the time to respond to the question. Here's a look at the actual voter breakdown:

  • 76% said they would like to see Swing packaged in java.awt.swing for use with JDK 1.2

  • 15% said they would like to see Swing packaged in com.sun.java.swing for use with JDK 1.2

  • 9% were unsure, or offered a different opinion

Below is a representative sample of the comments collected in the poll. To see all comments from this and other JavaWorld reader polls, head to our archive of past polls. And, of course, don't forget to voice your opinion in our latest poll.

I would like to see Swing packaged in java.awt.swing for use with JDK 1.2 (76%):

Just call it com.microsoft.awt.swing. And the next new package might be called com.ibm.awt.* or maybe com.xerox.*. Lets see...Java is an ISO standard...not a Sun proprietary language. Microsoft will have a good laugh over this one.

Sun should forget justifying future bad decisions using past mistakes. This is far too common in this industry.

It seems that Sun is just asking for trouble from Microsoft by putting the crucial Swing package in the vendor-specific hierarchy com.sun.*.

The vast majority of Swing-enabled applications aren't written yet -- and for these the transition wouldn't be a problem at all. By changing the package name Sun is: 1) making a huge opportunity for Microsoft and co. to try to evade the library, if not by law at least in court of public opinion; 2) making a precedent of not naming a core library with the prefix java.* (and I'm afraid this one won't be the last, thus making it hard for developers to remember what is core and what isn't); 3) making an ugly aesthetic exception to the naming scheme; 4) not making it preferable for users to migrate to Java 1.2 as fast as possible; 5) missing an opportunity to make a coherent library with the rest of the API. In a few years nobody will remember Java 1.1 or before (thus the naming exception will be short-lived), but the inconsistent naming will remain forever. As a developer, I urge Sun to reconsider the recent decision and do the right thing -- name it java.awt.swing!

Do it right. Don't kludge for compatibility; it will come back and bite you later.

It's very important that Swing is a core component of the Java API and therefore should be packaged that way. It breaks all the rules to have a com.sun.* package part of the core API, and will inevitably lead to problems.

It seems to break the standard naming conventions, is confusing, and is detrimental to the Java platform's simplicity in the name of backward compatibility, not to mention opening the way for future nonstandard naming! I think it is wrong, and that complete backward compatibility should wait until Java is a solid stable platform that doesn't change every few months!

Not having the package in java.awt.swing will make it too easy for Microsoft to claim it's not really core, no matter what Sun says, and omit it from its VM.

The effort of migrating existing software to a different package name is a blink of an eye compared to complexity added by introducing unnecessary exceptions to an otherwise simple and precise rule.

With the advent of the Java Lobby and initiatives such as Kaffe, Guava and Kore, there is no reason the Java community should support Sun in any effort to make Java more proprietary. It seems to me that conversion utilities can't be all that difficult to build, and the Java Lobby and Wooden Chair are offering a Swing package converter right now. Besides, with the likely growth of many thousands of packages, developers are going to expect repackaging and refactoring tools as part of their development environments. The biggest issues with repackaging and refactoring of third-party code concern compatibility with yet other third-party code using and/or expecting the original packaging and behavior. I shudder to think about the proliferation of package wrapper packages. This will certainly not be an obvious or easy issue to resolve, but keeping all the core Java classes under the java or javax packages certainly makes a lot of sense to me and postpones any need to address this type of problem for the core classes.

Migration problems? Swing was a beta. If you used it without considering the consequences, it's your problem. Don't ask everyone else to suffer forever because of your poor software construction practices. This lazy mentality is why the software industry "enjoys" its (deserved) reputation for poor quality products.

It appears to be a short-sighted short-termed solution just to enable people to use Swing in Java code running in browsers.

I feel that Sun ought to release the Swing package as soon as possible to perpetuate the momentum of developers using Swing (Swing is cool), but it needs to be in the core. Sun should make a transition release and then provide a migration path for the package to be added to the core (the migration tool should be free). Sun should provide some guidelines to developers so that the migration tool will work correctly. In fact, it could call the non-core release a "deprecated" section.

If Swing is to be considered part of the core Java API, it really must be included under the java.* hierarchy. Otherwise, there will be no end of argument on the part of Microsoft and others as to whether or not their VM implementations need to bundle it.

I would like to see Swing packaged in com.sun.java.swing for use with JDK 1.2 (15%):

Since Swing seems to be receiving huge amounts of criticism, and is clearly not living up to initial expectations, there would seem to be good reason to exclude it from java.awt.

Keep the core light. The Java core should be light and all other fancy APIs should be in a separate package. This will allow us to use or not use Swing or a maybe-compatible-tomorrow UI API from someone else!

Finally, Sun has taken some action that is actually in the best interests of developers. Compatibility with JDK 1.1 is key, because of the advanced level of adoption of JDK 1.1. I think that Sun also realized that java.awt.swing would have been a non-event in the marketplace, because there is no way the classes will make it into the Microsoft VM. Whether these classes are "core" is something the market will decide!

Graphical user interfaces can be a personal, even religious, thing. I think Java should be treated as a foundational, enabling technology. That which exists in java.awt.* is the basic code to tie basic GUI components to the underlying operating system. That should be in the core Java hierarchy. The Swing components are a Sun-ism. By housing Swing under com.sun.java.swing, Sun acknowledges that it is a contributing company as well as a creating company. By this I mean that if other companies, groups, etc., wish, for whatever reason, to create their own GUI package, neither they nor those using the package will think it must be part of the core to have a functional and robust implementation. Sun sets a precedence for extensibility.

I'd like to see Swing labeled a standard extension, which would 1) allow bare-bones VMs to leave out swingall.jar; 2) allow Sun to release Swing updates and patches separately from the rest of the JDK; and 3) make it easier for other products to compete on equal footing. That means a third choice is required: javax.swing. But since a large number of apps already use it, com.sun.java.swing will probably have to stay.

Rewriting apps when you upgrade the JRE is not part of the agenda for Java. And as I am presently deploying a large financial application for java worldwide, the thought of going to my line manager and saying we need to rewrite the code (change the import statements) when we upgrade to 1.2 will not go down well!

Leaving it where it is will be easiest for migration reasons when moving from JDK1.1 to 1.2. However, I personally would rather see Swing in the javax.* hierarchy. It's a big package and a lot of baggage if you don't need it, but I feel it is more central to Java than the com.sun.* package implies.

The whole idea of naming packages with the domain name is that the owner of the domain name can put whatever he or she likes there. This applies to Sun as much as it does to the rest of us. There was a big outcry when Sun originally announced it was going to move Swing when 1.2 was released. This decision shows that Sun has early adopters' concerns at heart and I applaud it.

It seems that the majority of people have overlooked the main problem here: Java's packaging mechanism. As long as we hard-code package names, changes like these are going to be painful and expensive. I think some kind of "package map" is required. This could be supplied to class loaders, and would describe how classes should be packaged. Hence, class-name ambiguity is resolved at runtime.

Don't know/No opinion (9%):

java.swing or java.jfc seems to be the most reasonable location to me. Updating existing code is no big deal (and Sun could probably easily provide a tool if it wished to), but there would seem to be some need to provide a mechanism whereby one could run 1.1 Swing code under the 1.2 JRE without making the changeover, as we will undoubtedly end up encountering both 1.1 and 1.2 JREs in browsers or on desktops for a significant while.

I think Swing should replace the AWT completely. The AWT is such a load of crap, why make Swing a part of it? I vote for java.swing.*!

Neither package name seems correct to me: Swing is part of JFC, and thus should be added to the JFC hierarchy.

Swing is a great idea but not ready yet for the big league. Stuffing Swing into java.awt simply sets the stage for yet another version upgrade in a short time. Code compatibility is a non-issue, as so many workarounds have been offered, so there is no longer any legitimate reason to consider com.sun.*. I think java.swing or javax.swing make sense until java.awt can lend itself to the dynamic addition and deletion of classes.

How about com.crappy.language.design.swing?