Desktop Java: Having Choices is a Good Thing
- By Matt Stephens
- September 28, 2005
Java programmers certainly can’t grumble about lack of choice when it comes to desktop development toolkits. (The same is also true of Java server-side, of course, which has a proliferation of webapp frameworks and APIs).
To summarize, here are what I consider to be the three “major” GUI toolkits for Java (okay there are others, but these three have the most mindshare and are starkly differentiated from one another):
Swing: the “standard” toolkit, built into the Java runtime. Non-native; that is, it emulates the native UI rather than re-using it, but has the advantage that what you see on Windows will also be what you see on OSX, etc. Very mature toolkit, and tends to be the default choice for many developers.
wx4j: Open-source toolkit, a thin Java wrapper around wxWidgets (a mature, cross platform, native widget C++ toolkit, which itself provides a thin wrapper around the underlying OS shell). wx4j has the advantage that it will always look and behave exactly like a native Windows (or OSX, etc) system.
SWT: Kind of like wx4j, except using its own home-grown native wrapper instead of something like wxWidgets. As a result, its component set isn’t as mature as it could be (yet!).
All three of these GUI toolkits are portable, in the sense that you can write an application using them on, say, Windows, and it'll also run on OSX, Linux, Solaris etc without having to rewrite or recompile your program.
A recent JavaLobby thread suggested that SWT should have been built on top of wxWidgets, just like wx4j. Using wxWidgets would cut out maybe 70% (POOTA - plucked out of the air) of the SWT team’s work for them.. Additionally, wxWidgets has been around for a while, is stable and mature, and has the momentum of more than one major windowing API being built on top of it.
On paper, it would make some sense for SWT to be rewritten to use wxWidgets. But of course, it’s unlikely that SWT would undergo such a major and fundamental re-architecting when arguably it isn’t exactly broken in the first place.
Plus of course, wx4j already does the “Java wrapper around a native wrapper around the native toolkit” approach very well. So really, SWT should steer clear of doing the same thing, because, from a technical standpoint at least, there would suddenly be very little to differentiate SWT from wx4j.
wx4j, while being capable and plugging a worthy gap in the market, hasn’t made a big hit mainly because it doesn’t have the backing of a big player like Sun or IBM. It also doesn’t differentiate itself enough, or have enough (or indeed any?) high profile success stories to give it some credibility – very much a chicken and egg situation. But wx4j’s day could still be on its way, if it continues to quietly, steadily build up a solid user base of its own.
Ultimately, it’s good to have at least three toolkits each with a markedly different approach (even if the vast majority of teams will continue to choose Swing by default). It’s a healthy state for the industry to be in.
(Of course, on the downside, the market for high quality Java components is a tad on the impoverished side, especially when compared with Delphi and .NET. The notable Java players are JGoodies, JIDE, and that's about it. But that's a gripe for another day...)