Skip to main content

Toasting Java GUI's

Posted by editor on November 5, 2003 at 3:06 AM PST

My last weblog entry generated some good discussion about Java GUI builder tools and how they should work - how they could be made to save serialized objects instead of code, and how some apps already do this.

A couple of people made the point that new and better GUI tools won't necessarily result in better applications. jeremyzacker writes:

The problem with Java GUIs isn't the language, its the notion that any Java developer can write a GUI. Java makes it so darn easy to write GUI code that people who would normally have nothing to do with a GUIs think that they can write one.

He goes on to note that the real problem is with developers who don't understand threading and the Java AWT event-dispatch/repainting scheme, who block the GUI and create apps that appear slow or prone to freezes. Good point, and one that was directly addressed in a recent java.net article by Jonathan Simon. I ran in to similar problems a while back and blogged on ONJava about it.

In a way, this ties back to how I kicked off all of this with a mention of my session at the OS X conference, which in discussing Java's perceived slowness, asked the question "Java often used for enterprise / nework apps... does network latency look like a performance problem?"

Sure, you could save some time laying out your GUI with a visual tool... but is that really the hard part of developing Java GUI's? In the last couple of years, I've done complex GUI's, and yeah, I blow half a day on 500 lines of GridBagLayout code, but the parts that seemed challenging to me were some of the parts I did myself - multi-line list labels with icons and different fonts, a historical performance widget that rendered itself as a bar with colored segments representing performance over a certain time-slice, a JTree that supported drag-and-drop to its contents by tracking the drag event's (x,y) and repainting the node underneath based on whether it could accept the drop, etc.. A GUI builder isn't going to help with that, and I don't think those kind of tasks are any easier outside the Java world. Sometimes doing Neat Stuff requires getting your fingers dirty.

And maybe I've gotten off track from my original point. The Q&A for my session did get deeply into why we don't have an Interface Builder - like tool for Java, but one of the points of my presentation was that Java developers have turned out a disproportionate number of developer tools. We've got JBuilder, Eclipse, IntelliJ IDEA, Netbeans, BlueJ... and yet not one Java app that really matters to end users.

I keep having this troubling analogy in my mind, that Java is like one of those college degrees whose only practical application is to become a college professor in the topic.

If you haven't read the slides yet, this is "Why Mac Users Hate Java". They were promised that they'd get more apps out of the deal, because developers would stop writing Windows-only apps and start writing stuff in Java. Hasn't happened. Because those developers don't have pretty tools? I doubt it. I think the people who didn't care about non-Windows platforms in 1997 still don't care about non-Windows platforms and continue to write native apps (or worse, they write Java apps that only work on Windows). To a degree, many cross-platform apps that might have been written in Java have instead been developed as web applciations - MapQuest replaces the Rand McNally CD-ROM, TurboTax.com replaces the TurboTax CD-ROM, etc. And maybe these are done in J2EE, so we really are using Java.

But I digress. The point was, is it the lack of better GUI building tools that has held back Java on the desktop? I don't think so - I think the hard part of delivering a Java GUI has to do with things like threading and custom painting and delivering a polished, intuitive user experience... things that a GUI builder doesn't address. If an app is worth doing, then hard or not, developers will find a way to get it done. In fact, it's more typical that something cool is done the hard way first, to prove it can be done, then is made easier through a process of refinement.

To my mind, we're still struggling to come up with really good applications for Java applications... we'll work through the GUI stuff once we figure out problem domains where being cross-platform is critically important, where only a Java app will suffice. So I think we need to stop trying to please developers and start trying to please end-users.

Related Topics >>