 |
 |

September 1998

FUELING INNOVATION
Search
Topical index
Net News Central
Developer Tools Guide
Book Catalog
Writers Guidelines
Privacy Policy
Copyright
ITcareers
Advertisement
|
 |
 |
 |
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
By Michael O'Connell and Jenni Aloi
hen
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?
|