Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Has Sun Given Up on the Desktop?

Swing's reputation has been muddied time and again, leaving the Java platform, as a tool for desktop GUI development, severely and needlessly damaged. And Sun, who should be its eager protector, has merely looked askance. Contrary to what Sun might think, what Java needs most of all is a push for desktop application supremacy.

ava is no longer the new kid on the block. Its original promises are no longer "wait and see" propositions. We have waited. We have seen. And though I could offer much praise for the progress of the Java platformthe areas it has matured (enterprise distributed component technology) and the new territory it has rushed to address (Web services and peer-to-peer)I can't help but sense incredible unrealized potential. While the pundits scour the market for the next new technical sensation, I believe Java on the desktop is, or at least should be, the next new thing, and Java's GUI competitors are ripe for the kill. It's time for Sun to serve up a second cup of Java, and Swing desktop application supremacy should be the new Java brew. Yeah, that's right; you read that correctly: Swing desktop application supremacy. Why procrastinate with controversy? Let's rock!

That Old Battered Swing
Once upon a time, someone espoused the notion of a "write-once, run-anywhere" language. I cannot count the number of times since that I have encountered variations of the following criticisms: "Java has not delivered on the write-once, run-anywhere promise" and "Java Swing is not good for GUI development." I have heard it from customers, from software companies, and read it on countless mailing lists and trade press articles. Even positive comments about Java are often barbed: "Java excels on the server side." Quite true, but this comment suggests that Java is an undesirable platform for GUI development. Such comments are the equivalent of hearing that your blind date has "a good personality."

Sun needs to control perception by marketing Java GUI applications like they were the Eighth Wonder of the World.
You can't blame Sun for playing to Java's strengths and where it has gained acceptance, which is primarily on the server side. However, Sun's efforts to leverage Java's server-side acceptance to promote more development of Java GUI applications has been almost non-existent. And whether intentional or not, Sun's ambivalent attitude is tantamount to a forfeiture of the desktop software market to Microsoft. Microsoft has not been idle, and never will be, in trying to discredit and downplay the Java platform. Sun cannot be forever passive with regard to Swing and expect Java to hold and expand its prominence.

Sun needs to realize that the Java platform can't survive against Microsoft indefinitely as a server-side technology only. The desirability of a server technology extends only as far as the ability to interface to it. Server interfaces can be accomplished in Java by writing custom code, but the majority of development efforts should not require writing a new custom networking layer. J2EE, the enterprise distributed component technology, is heavily coupled with the underlying RPC protocol, Remote Method Invocation (RMI). Thus far, Web interfaces have alleviated the need for the majority of clients to speak directly to the server via RMI. HTTP has done the job. But if the need for rich GUI feature and application interoperability exceeds the desire for J2EE server technology, the desktop application technology (and hence, the RPC protocol) could be a greater threat to J2EE than any server-side feature of .NET. Web services eases this threat a little, but not a lot; Web services are ideally suited for integration points, but not for every remote call in an application. I think Microsoft understands the desktop threat better than the Java community does. Was Microsoft's early decision to drop the Java Virtual Machine from XP an attempt to eliminate Java completely? Maybe, but perhaps it was designed to address a more specific threat to Redmond: continued penetration of Java GUI technology on Windows.

Widening the OS Rift
Any significant degree of Java Swing GUI acceptance likely means two things: 1) customers will demand cross-platform (rather than single-platform) licensing (which means lower application licensing revenues for companies currently licensing platforms separately), and 2) commoditization of the operating system. This latter consequence couldn't come at a better moment. Operating system debates (primarily over Windows, Linux, and the compelling re-entry of the Macintosh with OSXbuilt on the BSD kernel) are raging longer and louder than they have in a decade, and this widens the opportunity for Java on the desktop. The more computer users divide over their operating system preferences, the greater the need for applications that are liberated from any particular operating system. Swing GUI applications need to gain broad acceptance, not only for the good of the Java platform, but to prevent a clever marketing wind from blowing out of the Northwest and tainting the true innovation that Java delivers on the server side. Why isn't Swing the de facto standard for GUI development? The first reason is perception. Sun has allowed its competitors to successfully label Swing GUI applications as second class. Swing has a reputation for being a slow-performing, memory-consuming API.

If you have a basic understanding of the Swing architecture you know that there are real architectural reasons that Swing consumes more memory and gives ground in performance to native GUI applications: Swing components have to duplicate much of the work that is handled by the OS in native applications. But this reasoning assumes that nanoseconds or even milliseconds are a relevant metric for GUI application benchmarks. The acid test for a GUI is usability, which is a completely different standard. And, as hardware processing capability continues to improve apace, I find it hard to believe that Swing cannot exceed performance requirements for the vast majority of applications. In my experience, Swing performance is more than adequateit is the supporting code and architecture that is lacking. There is a more pragmatic reason behind Swing's guarded success: ease of use. Visual Basic, the most logical competitive parallel for GUI application development, is terribly easy to use and is supported by an intuitive IDE. Sure, VB is boring and limited as a programming language (albeit with significant improvements in .NET), but it has made GUI development a reality for even non-programmers. Swing, on the other hand, is an entirely different beast.

The object-oriented nature of Swing GUI development isn't hiddenit's in your face. This frustrates many GUI developers, who are accustomed to developing visually, rather than by architecting via object hierarchies. Swing requires a good bit of savvy with object-oriented programming if you are to avoid weighing down rich GUI applications with event handler objects. I have often observed projects in which creative personnel, who are often not strong programmers, are pushed into GUI development. And with Swing, this can be deep water. Consequently, many Swing GUIs are poorly architected, contributing to the perception that Swing is a performance dog. It is time for Sun to get waist-deep in the battle for desktop application supremacy. Let's not candy-coat it: this is assaulting Microsoft on its home turf, where it is strongest. But I think it is a winnable war. And more importantly, I don't think Sun can afford not to fight the battle if Java is to remain the market-leading development platform.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date