Eitan Suez's Blog

Swing 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.

To swing or to web, appears to be a big question

When starting a new project, the User Interface decision is always a big one. Should we use Swing? Or should we develop a web-based solution? Some also are correct to argue that web-based doesn't necessarily imply HTML-based. Macromedia-based web solutions are not only viable but a real player. In certain circumstances, the requirements make the choice fairly clear, possibly even mandated.

The traditional trade-off, whether true or not, has always been along the lines of: "give up richness of the UI that comes with Swing for a rapid development cycle that is the web." Developing UIs in Swing does seem to require more skill, knowledge and experience with a very large API. It didn't use to be so with HTML but new standards have crept up over time: CSS for styling, various XML technologies for keeping content away from presentation (XSLT perhaps, now XQuery is on the horizon). But developing web-based solutions also implies knowledge of relatively new frameworks such as Struts or Tapestry, maybe Cocoon. For Struts, one also has to be familiar with underlying technologies such as JSP, Taglibs. JSF is now the newcomer and JSTL has surfaced. So does the web way really look like a "piece of cake?"

Some have argued (and I agree with them) that a tremendous effort has built layers of abstraction on top of the HTTP protocol to make the web a platform for building distributed applications. Their point is that the web was never intended to be such a platform. From this angle, it almost feels wrong to try to "shoehorn" the web for web app development.

Traditional developers sometimes are offended when they see web-based apps violate principles that they would never even consider bending: having to make repeated calls to the server to get back the same information over and over again: headers, footers, markup that could easily be cached otherwise (that is if Swing were used instead of a web browser).

I very much enjoyed reading Amy Fowler's article on JDNC (Java Desktop Network Components) on JavaDesktop.org. Amy's article clearly sums up the debate between web'ers and swing'ers. JDNC hopefully will narrow the gap some more.

It's interesting to analyze how "the gap" has narrowed thanks to various technologies introduced in both camps to help them overcome their weaknesses. On the swing side, there's a lot to talk about: we've had Java Web Start for a while now and people are using it more and more. Also, I really like the frameworks that have embraced a pattern which is admittedly a good one used in the web world: that of using markup to define the layout of a user interface. Allen Holub's recent JavaWorld article on HTMLPane shows how one can make use of this pattern in Swing applications. In my mind the kudos should go to the folks who are building frameworks such as Thinlets (www.thinlet.com), and XUL. They're taking the idea to an entirely new level.

Now here's the one that I think takes the cake: NakedObjects (NO). This framework looks at things clearly, and from a perspective that I believe has almost been entirely overlooked by most. The idea is simple: don't waste your time writing user interface code. It's the same thing over and over again. Instead, use a framework that will draw the User Interface on your behalf; you just concentrate on your business logic, what you're supposed to be doing anyway! :) I have to admit the NO folks have a point. If you haven't done so, I recommend reading Richard Pawson's and Robert Matthews' book "Naked Objects" (http://www.nakedobjects.org/book.html). Yes, I agree that today there do not exist very many NO-like frameworks. NO is a terrific tool for prototyping applications. It's the only way to go for prototyping. One can so quickly develop a prototype application that can be placed in front of a customer, facilitating communications and feedback with the customer.

NakedObjects and various related development efforts today can take the same business logic and give you a user interface in AWT, Swing or DHTML. That said, the Swing version is 0.4, the DHTML version is also somewhat experimental. But it proves the point. I believe NO is a glimpse of things to come and sincerely hope that within 10 years the idea of painstakingly crafting user interfaces by hand will be a thing of the past.

This work is licensed under a Creative Commons License.