Java enjoys something of a tarnished history, in some ways. Originally held up as the penultimate client-side technology–everybody remember when “Write Once, Run Anywhere” was the sole slogan for Java?–Java has since more or less abandoned its client-side roots in favor of its success on the server-side in J2EE. And yet, Sun just can’t quite give up on the idea of “Java everywhere”: server-side, client-side, even PDA-side. They sink millions of dollars in time and salaries in perpetuating the Swing libraries from one JDK release to the next, all to be greeted with comments like, “Java Swing is not good for GUI development” or the more colloquial “Swing Sucks”.

Realities of Economics

Let’s establish a few facts up front here, before we continue with the analysis:

  1. Sun is engaged in a fight with Microsoft over the future of enterprise computing. Anybody who doesn’t see this needs to stop talking to the volleyball. It’s .NET vs J2EE, no holds barred, with the referee (the DOJ) taking a coffee break and munching on a donut.
  2. Sun is smaller than Microsoft. This is another indomitable fact–Sun simply doesn’t have the same kind of resources to throw at Java that Microsoft does at .NET, particularly when we stop to realize that Sun is also a hardware manufacturer, and derives much (most?) of its income from that line of work.
  3. Software development requires resources. Money for infrastructure, money for salaries, employees’ time, these are all non-trivial costs associated with any particular software (or standards) development project. Resources are finite (thank you Keynes), so Sun needs to make sure that the investment in resources yields commensurate payoff–not in “web presence”, which was sooo 1990’s, but in hard cash.
  4. “You cannot strengthen the weak by weakening the strong”. This quote, by Abraham Lincoln, highlights a key principle: sinking money into something that’s not yielding results, when that money could go into something that does, is not a great business prospect. Medical guys call it triage. Business types call it “rightsizing”. I call it “smart investment”.
  5. Further development is necessary. Swing needs additional enhancements, and will always need additional enhancements, for the lifetime of the project. Changing UI guidelines, new looks from Microsoft (among others), new hardware that needs to integrate within the UI, all of this represents a perpetual employment curve for Swing coders. Can you say “Big Black Hole”?
  6. Portable GUIs are hard. Without exception, Swing is the largest project in the J2SE library, and easily (I’m guessing) represents more than half of the development effort for any given J2SE release. Consider the staggering goals of this project: to produce a cross-platform, natively-drawn, GUI toolkit. I remember going through this phase back in 1992-94, when C++ ruled the roost and toolkits like XVT, Zinc, and zApp promised cross-platform applications with just one source base. “No #ifdefs!” was the rallying cry. The problem is that this kind of transparent portability is hard. Very hard. So hard, in fact, that none–count them, ZERO–of those toolkits survived. (Rogue Wave, a company that acquired one of those toolkits, still exists, and their C++ libraries are still available for purchase, but there’s zero new development going on there.) None of those toolkits even attempted to do all the screen-painting natively, either, when complaints that “the GUI just looks wrong” when rendered with native components (think AWT here) came up. The goals of Swing are HUGE.

Swing != Payoff

For just a moment, let’s give credit where credit is due–Swing represents a HUGE success, as far as I’m concerned. Sun has created a library that, more or less, does what it’s supposed to. Yes, it has bugs. Show me a project larger than “Hello, World” that doesn’t. Yes, there’s functionality we’d love to have that wasn’t there to start (think mousewheel), but Sun has been slowly folding that support in. Themes, portable look & feels, a rich model/view architecture, non-trivial controls (JTree, JTable), Swing definitely hits a triple. It’s portable, you can write functionally usable applications using it, and it has a rich set of UI functionality available to you.

But, as O’Hearn notes, Swing is hardly a resounding success across the board. Running on light hardware, Swing crawls–because, in order to maximize its UI portability, Swing has to draw each and every pixel in the window itself. Swing apps “just don’t quite look right” to many users–the look and feel just “stands out” compared to other applications for whatever platform you’re running, even using the native look & feel for that platform.

Let’s not forget that Swing is entirely free–the entire development cost of Swing is a drain on their development budget, with no income to compensate. Frankly, this doesn’t make much business sense, unless you believe that people wouldn’t use Java if a UI toolkit wasn’t available. One is (AWT), and gets people “just far enough” that students and hobbyists you want to build apps with it can do so. If a company wants a professional-looking application, isn’t it worth some money to them to get a professional UI toolkit?

Let’s also not forget that this race is far from over. Java has had more than five years in which to build a lead against Microsoft, but that grace period is over. Any opportunities to make mistakes and not pay for it are long since gone. From here on in, it’s a knife fight. Sun needs to keep their focus tight.

No Swing? No Way

That Java wants a GUI library to ease developer efforts on client-side applications goes without question. As O’Hearn notes, “Sun needs to realize that the Java platform can’t survive against Microsoft indefinitely as a server-side technology only”. Particularly, as I’ve already noted before, the “rich client” (as opposed to the browser-based “thin client”) is about to begin a renaissance, and full-featured UIs are coming back in vogue. Not having a rich client technology here would be almost fatal, because it will be far easier to go Java-to-Java client-to-enterprise, rather than .NET-to-Java. If .NET WinForms become the de facto choice for doing client-side development (and WinForms face their own adoption curve, make no mistake, so this isn’t a guarantee by a long shot), it’ll be very easy to give in to the temptation to just go .NET-to-.NET.

That Swing needs to exist is not up for debate. But does Sun really need to be the driving force behind it?

Turn It Loose!

Question: What would be the result if Sun simply turned all Swing development over to the community as a whole?

We’ve already seen the huge success a number of Open-Source projects have enjoyed in the Java space: Tomcat, Ant, Crimson, Axis, the Jakarta-Apache Group is an amazing collection of people that have created an amazing set of tools and code. (My personal favorites: Ant and BCEL.) It’s not unreasonable to assume that the Swing libraries would get good attention once released. It’s also not unreasonable to assume that Swing would remain as the preeminent “standard” for developing native UI applications, just as Tomcat and Ant and preeminent “standards” in their respective areas.

What this does most of all, though, is:

  1. free Sun to take those hordes of Swing developers and either contribute them back to the open-source effort (as they did with Tomcat), or move them onto other projects,
  2. bring far more developers into the halls of Swing than Sun could ever hire or pay for, and
  3. earn back some respect from the open-source community that our dear buddy Scott McNealy burned with his comments about open-source J2EE efforts.

These are not intangible benefits, and most of all, seems to represent a win-win for everybody. The Swing Connection could move to jakarta.apache.org, the developers there could become the nucleus of the open-source Swing community, and Swing could “keep up” with platform developments at almost-zero cost to Sun. This sounds like a good result to me….

Thoughts?