Eitan Suez's Blog

July 2004 Archives

Experiences with Swing

I've had the pleasure to work on a Swing application these recent months, and I'd like to share with you one of the main conclusions I've arrive at.

It did take me a little time to gain fluency with the APIs. After all Swing is a fairly large API (over 600 classes). On the other hand, once that fluency is gained, developing in swing works out all right.

Specifically one quickly realizes how powerful and flexible Swing can be. For example, I wanted to construct a hierarchical JComboBox and it didn't take much to actually make that happen. I was able to devise such a widget (which I called JComboTree) by combining a JButton, JPopupMenu, JMenuItem, with a TreeModel.

Second, there's no denying that the Swing developer community is a large and active one. Many developers subscribe to the forums, submit their questions, their problems; they contribute their code, their ideas. It's all good (think Bruce allmighty :-)).

One even goes as far as finding all kinds of third party additions to Swing that fill in the gaps: things that a business developer would need but doesn't find "out of the box," incorporated into the Swing API. Let me give you an example: to support my particular Swing application, you will find these third party libraries:

1. additional (awesome) layout managers from jhlabs.com
2. a jar file that bridges the gap between rendering a hyperlink and actually launching it in a browser (browserlauncher.sourceforge.net)
3. skinlf, to give my app additional/alternative cool skins (an alternative is jgoodies)
4. jcalendar (widget for picking dates, displaying a month view)

Furthermore, if you don't find the Swing tabpane API good enough for your needs, you'll discover that the netbeans team wrote their own separate tabpane API. You'll also discover little pieces of clever code in the forums to give the existing tabpane API a few more features (such as displaying an 'x' on each tab to allow a user to dismiss them, like one does in mozilla for example).

You'll also surely come across various articles that have been written over time that show you additional nify and useful widgets written by various developers. One example is a swing TreeTable, that merges a JTree with a JTable, to allow one to display multi-column rows where the first column is a tree that allows nodes to expand and collapse. Another example is Alan Hollub's calendar widget (employing the decorator pattern).

Now, take a moment to think about the amount of time and effort I've spent: discovering these add-ons, learning to use them, trying out a bunch of them and figuring out which ones worked for me and which did not; which are mature enough and which are not.

Then comes that point in time where you scratch your head and ask yourself: why are these features not incorporated over time into the Swing API? Why isn't the developer team in charge of maintaining and developing the Swing API doing this type of work? This is exactly what a good software library manager does: they're in contact with the community, they distill various enhancements and contributions from the community. They keep the best ones, or work on the promising ones and finally incorporate them back into the Swing API. That's in essence what Redhat does for Linux. That's what Eric Raymond talks about in his various open source essays: how to be a successful open source software manager.

[IMHO] Therein lies the problem. I don't want to guess because I have no clue and I'll admit it. But something tells me that there's a mismatch. The swing libraries are not exactly open source. I'm sure the Swing team wants nothing more than to make our lives easier. Something tells me that this crucial last step of incorporating contributions back into swing is failing because of legal restrictions.

Swing could be more than just "nice," more than just "ok" or "i can live with it." Swing could be the most awesome thing out there. If only through the magic of open source development. The community is already there. The code is waiting to be integrated. What do we need to do next??

I believe that the good people at Sun are actually a step ahead of me. A number of recent announcements indicate that things are moving in exactly the right direction: JDIC and JDNC have been released. I can tell from the community reaction that these new libraries are terrific. Issues such as the ability to easily launch a hyperlink in the user's preferred browser are being addressed. What's really awesome is that these libraries are released under the LGPL.

Structure of J2SE: Modularity

With 2604 classes in J2SE v1.4.2_05, one could say that J2SE is a large API. I mean, compared to other APIs, such as dom4j (153 classes) and hibernate (466 classes), J2SE is large. Of course, you'll argue: "this is not a fair comparison: J2SE is an aglomeration of multiple APIs, packaged together as one large bundle." One should instead compare dom4j and hibernate with APIs such as jdbc, swing, awt, jndi, jta, rmi, security, util, xml, etc..

My point exactly! I'm glad you brought this up. [AFAIK] Java was the first language to introduce an official, structured, and coherent namespace mechanism to separate my code from yours, code that does X from code that does Y: packages. And packages are terrific! Over the years, and with the growth of the Java platform, I've come to believe that yet another level is missing: some kind of uber-package. Maybe we should simply call it an API. We need something to bridge the gap from "package" to J2SE. This idea reminds me very much of what the folks at W3C do with their specs: with time, new revisions of specifications grow to a point where spec authors decide to modularize them. For example the CSS3 spec is comprised of a few dozen modules (fonts, lists, borders, text, print, media, etc..). The latest DOM and HTML specs are also modularized.

Back to Java, I'd like to see J2SE more formally modularized. I mean, I know that all packages that begin with javax.swing a part of the Swing API. I'd still argue for a more formal modularization mechanism. As I browse J2SE javadocs, I'd like to see a first-level hierarchy of APIs, not packages. I see this as a natural "cleavage point" (so to speak). And in fact, somewhere under the java.sun.com web site, you'll actually find home pages for each of these J2SE "sub-APIs." I'd like to go as far as select what J2SE APIs to include in my javadocs to begin with (perhaps because I may not need to use them all on a specific project I'm on).

This reminds me of something else (here I go on yet another tangent): there's this informal rule that average humans have difficulty remembering lists longer than seven (7) items. J2SE contains 114 packages. That's definitely more than 7. If we were to introduce this extra level, we could nominally bring things back, closer to that rule of seven: J2SE could be comprised of maybe a dozen sub-APIs, each containing maybe 8-10 packages. That'd work for me!

As far software packaging/download purposes are concerned, I'm actually happy as a clam with the current state of affairs.

This work is licensed under a Creative Commons License.