Another Take on Swing and Java's Success

by Marc Hedlund

Related link:

I enjoyed reading Ted Neward's weblog on The Success of Java, but I disagree with his conclusions and I have an alternative proposal.

I agree with one of the reader comments on Ted's article, which says that creating GUI code is not something open source projects have done particularly well. The reader points to shipped GUIs like GNOME and KDE, and certainly there are other examples in this vein. I would go a little further and say that GUI APIs are probably even more removed from the strengths of an open source project model. Not only must the API itself be internally consistent and easy to use, the effects it creates -- that is, the look and behavior and defaults -- must be externally consistent as well. I certainly would say an open source project could succeed at such an effort; but I would also say I haven't seen it happen yet, and it would take more -- much more -- than Sun dumping a ton of code into the ether for it to happen.

(As a side note, I think there's a very interesting project waiting to be done: an analysis of the governance and participation models of various open source projects. I've suggested this to Tim O'Reilly in the past and I would do it myself if I had more time. Linux and Perl and Apache, three of the most widely-referenced open source successes, have three incredibly divergent models for controlling change and inviting participation. The leadership models are radically different, the histories are rich, and arguably the nature of progress and evolution varies between them. I'd love to see in-depth interviews with participants in these and other projects, with some resulting prescriptions for how to run projects under the models suggested by Linux's "benevolent dictatorship," Apache's "meritocratic representation," Perl's "monarchy and prime ministry," and others. Relevant to the Swing discussion, an open sourcing of Swing would need, in my view, either a benevolent dictator or a monarch and prime minister model -- the representative governance of Jakarta seems the worst-suited to the level of consistency and integration needed for GUI development. The closest analog is Perl, not Tomcat.)

In any case, we could argue about whether an open source GUI project would succeed or fail. We could even argue whether the development of Swing is really a problem -- I think Swing is an excellent API hobbled by the horrible desktop performance of Java. Instead, I'd like to set this aside and make an alternative proposal for Sun and the open source community around UI development and the Java libraries.

One of the most tantalizing things I've found in C# and the .NET platform is the close relationship between Windows Forms (the .NET analog of Swing) and Web Forms (the .NET analog of JSP). When you look at these two APIs, you can see that Microsoft is pushing them as closely together as possible. Why? Well, here's what Microsoft says on the topic:

The next generation of Visual Studio will dramatically reduce the complexity of creating the next generation of Web applications. Visual Studio developers will be able to develop applications targeting the Web using the same paradigms with which they build Visual Basic applications today. With new, simplified techniques for Web application development, and with inherent support for industry standards such as XML and SOAP, Microsoft will help Visual Studio developers create the next generation Web.

In other words, bringing the Web and desktop GUI APIs closer together will allow developers and applications to easily move between these two paradigms. I think this is an incredible benefit of C# and the .NET platform: you develop your UI in a common, easy to learn API model, and that model can be applied to Web (thin-client, connected access) interfaces and Windows (fat client, disconnected access) interfaces with a trivial amount of work. Your application operates the same way for your users, depending on their needs and environments.

Let's take an example of a sales database. In the office, the sales database is a Web application, accessible from any intranet browser and updated instantly with every piece of customer data. That's great -- as long as you're in the office. Salespeople, of course, travel all the time. With a Web Forms to Windows Forms port (and some help from ADO.NET, an elegantly complementary data access technology in .NET), your salespeople can use the same application in the same way, sitting at their desks in the office or disconnected on their laptops while flying from New York to L.A. Development porting time is limited, user education is minimal, and the benefits are clear.

Great stuff if you're a Windows developer and you can get the benefits of Windows Forms. What if you're a Java developer? Well, you're out of luck -- Swing and JSP are radically different, almost unrelated models. Taking a Java-based Web application and turning it into a Swing app is almost a complete rewrite of the interface.

Here, then, is a project where Sun and the open source community could work well together. The Jakarta project has done exceptionally well with server-based interface toolkits like Struts; Sun has done very well in creating a usuable and consistent desktop GUI API in Swing. These two groups should work together to meet the challenge of Windows Forms and Web Forms. Use Swing and its API as the model, and create a "port" of this existing, consistent API to the Web model (providing a desperately needed alternative to JSP in the process). This sort of porting effort is very well suited to an open source project. In addition, such a project could again show Sun's customers the benefits of working in a development environment supported by the open source community -- namely, that the growth of the environment is not limited to a single vendor's ideas and needs, but instead is fueled by collaboration of many companies and communities.

If Sun does nothing to address the strengths of Microsoft's Windows Forms/Web Forms model, that model might wind up being a wedge for Microsoft to break Java's server-side dominance. Show our hypothetical salesperson that they can get the benefits of a Web application with the interface of a Windows application, and they may never want to go back.


2002-09-15 13:20:47
XUL is the future, not yet another GUI toolkit API
The future of GUIs for rich desktop apps is *not* yet another API (a la Windope Forms, Eclipse SWT, Swing JFC, Trolltech Qt or whatever).

The future of GUIs for rich desktop apps is XUL (XML User Interface Language) along with XHTML (for styled text in XML) and SVG (for 2D graphics in XML) and CSS for styling.

With XUL the HTML story repeats itself. The big players and self-proclaimed innovation hot houses completely ignore the obvious benefits of XUL and instead push their own walled-garden archaic GUI toolkit APIs going nowhere.

It's up to freedom loving individuals to follow Tim Berners-Lee lead and champion XUL and make it happen.

Open-source projects such as Luxor - a GPL'ed XUL toolkit in Java ( ) - lead the way to end the Windope desktop tyranny.

2002-09-15 15:12:55
other options
I'm still not sold that XUL will make it. XUL really requires a wide deployment of Mozilla. Yes, it might happen, but not likely. There's just too much intertia to overcome and not much compelling reason to do so UNLESS Apple pulls out a miracle and becomes a much larger force on the desktop (I hold no dreams of Linux doing such a thing since so many Linux users are going to OS X).

However, XWT ( holds more promise. XWT uses a combination of XML and Javascript on the client and the bulk of logic lives on the server via XML-RPC or SOAP. Now the really cool part is that XWT apps are distributed via HTTP. But even better is that on Windows/IE XWT apps are natively compiled Java into Active-X apps. Thus they are fast and responsive. On other platforms they are Java apps, but I know XWT can be natively compiled into a plugin there as well (pretty sure that's happened with Solaris and Linux).

A final couple of other options that are similar to XWT are Flash or perhaps SVG (Adobe's latest plugin lets you do post/reply via HTTP).

I'm too lazy to register but I'll post my name,
Mark Wilcox

2002-09-15 20:00:11
It could be done, but perhaps not starting with Swing
I agree that having a common GUI framework/api for both desktop and web work is doable. After all Microsoft seems to have almost done it. However, I don't think that starting with Swing is necessarily the best idea, it's too complex.

In my opinion the first thing is to decide on is the sort of app that's being targeted. The Swing GUI lets you build pretty much anything, and so provides functionality, like the paint method, that would be very difficult to implement in a web setting. If the focus is tightened to just "business style" apps then the problem is more tractable. Maybe the system should be built from the other end, would it be possible to implement the struts api on the client?

With struts the biggest problem for client implementation is the use of HTML for the views. This would have to be changed. Here XUL could be useful for describing an abstract layout which would be used to autogenerate appropriate HTML and Swing layouts. Some sort of overriding scheme to allow replacement or enhancement of the generated UI would have to be provided, you can never always generate exactly what's wanted. Fortunately CSS should provide nearly all of the look and feel customization needed for HTML, and for Java suitable overrides of the generated code by subclasses could let the developer tune the appearance.

The ultimate would be to come up with a way to allow the client app to take advantage of the increased capabilities that reduced latency and so greater interactivity gives it. How can the two models of interaction, screen at a time vs field by field, be reconciled, or at least accomodated in a single framework.

I agree with Marc that GUI framework development requires the internal and external consistency that best comes from a strong focus. For most open source or free software projects this is most often best provided by a strong leader. Especially in projects where there is the perception that this is a chance to build a better mousetrap it's important to have some way to ensure that people are all working towards the same mousetrap.

Alex Moffat

2002-09-16 02:41:57
XUL runtime
I remember reading a couple of days back about attempts to provide XUL runtime - something along the lines of JRE. Mozilla need not be installed to use XUL if this project becomes a reality. I can't imagine Sun supporting any effort to standardise XUL.
2002-09-16 04:21:15
Wo'd showing the way?
>In addition, such a project could again show
>Sun's customers the benefits of working in a
>development environment supported by the open
>source community -- namely, that the growth of
>the environment is not limited to a single
>vendor's ideas and needs, but instead is fueled
>by collaboration of many companies and

Ironicaly, this statement is already true, but it's not Sun showing the benefits of an open source development community, it's Microsoft!

While you plead in vain for Sun to leverage the strengths of open source, the Mono and Open.NET projects are busily implementing clean, fully open source .NET implementations on unix. The mono project is also planning windows and web forms implementation for the future.

The upshot of this is that when Sun adopts GNOME as it's standard desktop, as it has stated it intends to, we may well end up with a fully open source .NET client/server application framework installed as standard on every Solaris desktop.

You couldn't make this stuff up!

Simon Hibbs

2002-09-16 11:41:16
Java Server Faces?

Isn't this what Java Server Faces are planned to accomplish?


2002-09-16 13:42:07
Java Server Faces?
Not quite. JSF seems to be more of an improved (over JSP) way to write webpages designed so that tool vendors can write tools around it. Doesn't appear to be a platform to produce both client and server guis or ease porting between client and server.

Alex Moffat

2005-06-08 20:18:29
Try JFCX on
I would like to note that I am making an effort to solve the problem discussed above with the JFCX project. There are really a couple of aspects with Swing that make it difficult to work with.

First, few take the time to understand how each widget uniquely implements the MVC framework and how flexible each component is as a result. Second, (and the down-side of the first point) the API is not "user friendly" to developers who simply don't want to have to think too hard to create GUI's.

In my opinion the Swing API covers about 80% of the everyday features that we all need. The rest usually needs to be developed. How the other 20% gets implemented can either open many doors or close them all.

I think a lot of the community (certainly not all) view desktop client development as a necessary evil to be offloaded to lesser skilled developers. I would argue that in a place where so much creativity and innovation need to thrive, the opposite would be ideal.

I invite you all to check out the jfcx project at It's open source (BSD license) and it's a work in progress. I'd like your feedback and hope that it can help you all.