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 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.The Recipe for Success
Sun must stimulate new interest in Java on the desktop. My recommendations?
Control Swing Perception
Sun needs to control perception by marketing Java GUI applications like they were the Eighth Wonder of the World, both to end users and development managers alike. No longer should the vast majority of what we hear about Swing come from those trying to destroy it. If Sun wants to tout the server side, then also tout Swing because it offers tight integration to that market-leading server technology. The industry needs to notice shrink-wrapped Java applications and loudly brand Java Swing technology so that it becomes a household name. “Powered by Java Swing” needs to be recognizable to techies and the layman alike.
Commoditize Office Applications
In my home network, I run Linux, Windows, and Mac operating systems. Excited about the latest Mac OSX release, I went shopping to spend a little money upgrading Mac software. But “a little money” was not to be. With a full license of Microsoft Office installed on my Windows machine (easy my Linux friends, I run and use AbiWord too, but this is a necessary compatibility thing), I was still faced with a $350-plus purchase price for Office on the Mac. This is utterly ridiculous.
The domain knowledge for Office applications is not foreign or proprietary, but very well known. And while the barrier for acceptance of an alternative Office involves other factors (such as file format compatibility), I find it lunacy that the industry-standard Office application still garners such high licensing fees for a single platform.
Sun needs to push shrink-wrapped Java applications of its own out the door, and it should start by finishing the race with StarOffice and marketing it heavily on Linux, Windows, and Mac platforms. Associating Swing with hundreds of dollars of savings on software purchases will be a welcome detail that people will appreciate and remember.
Mobilize a Community Effort
Sun needs to organize an initiative, whether internal or external, to promote the use, knowledge, training, and support of Swing and development of desktop applications. Perhaps Swing would be a good API to submit to the open-source community. By challenging the open-source community to commoditize the operating system by improving the Swing API and promoting the development of cross-platform Java GUI applications, Sun can invigorate interest in Swing development.
Create a New Swing Design Approach
There are two distinct tasks in Swing development: the visible mock up and the functional implementation. Current IDEs can handle initial visual designs, but any significant changes to the underlying code will render the visual editor useless. Most Swing GUIs I first developed in a visual editor never survived in the form rendered by the editor. I tore apart the generated code, and from then on I could not go back into the visual editor because it didn’t understand the modified code.
Sun needs to enhance the Swing API and/or create a new design tool methodology that allows the visual creation of Swing GUI presentation to be simplified and separated from the underlying implementation code (much in the way that XML and XSLT have attempted the separation of presentation and data in Web page design).
La Seconda Tazza
The Java platform is outstanding architecture. I thoroughly enjoy being a Java developer and singing Java’s praises. But even in its excellence, there are improvements to be made, and greater heights to achieve. Time will tell where Sun and our development community take the Java platform, but the answer will be increasingly bleak unless Sun turns a portion of its attention to addressing Java’s relevancy on the desktop. As for me, I am ready for that second cup of Java. Make mine a Venti!
