Skip to main content

Defrosting Java GUI's

Posted by editor on October 30, 2003 at 6:29 AM PST

I presented a session at the O'Reilly Mac OS X conference with the cheerful and innocuous title Why Mac Users Hate Java.

Seriously, it's not as bad as it sounds. Read the slides when they go up. What my research (I have a folder with 300+ web site postings and mailing list entries) showed that developers are very happy to be able to develop Java applications on PowerBooks and iBooks, even if they're deploying to another OS, a typical scenario for enterprise developers who deploy to Linux or Solaris. The second part of the session went into why end-users are dissatisfied with Java applications and yet why complaints of "slow, ugly, and irrelevant" could be trumped by applications that better exploited the potential of "write once run anywhere".

In the discussion afterwards, many of the questions focused on GUI builders -- a typical concern of developers, even though one of my rants was that Java developers have spent too much time on tools for other developers as it is. Specificially, they wanted to do something like Mac OS X's "Interface Builder" in Java.

The idea here is that instead of a GUI builder that spits out code, you'd have a GUI builder creating what Mac developers call "freeze dried" widgets. They're not code; they're properties like size, location, appearance, etc. At runtime, the objects are reconstituted and wired up to code. Obviously, in the Java world, this is a job for serialization, right? Instead of dumping hundreds of lines of GridBagLayout to a file with big nasty "do not edit anything below this line" comments, we'd have serialized objects that could simply be deserialized, then we'd make a method call to attach them to the rest of the application (the value of model-view-controller should be quite obvious in this scenario, where the "view" isn't even code anymore, forcing you to migrate your logic elsewhere).

If this is such an obviously nice way to do things, why hasn't it been done yet? Well, the straightforward serialization approach is kind of nuked by the warning that appears on every Swing widget's javadoc:

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. A future release of Swing will provide support for long term persistence.

Well, OK, fine. All Swing widgets are JavaBeans, right? In 1.4, we can serialize with java.beans.XMLEncoder instead.

So if this is such a good idea why isn't it happening? I don't know. When asked, I speculated that the Mac's Interface Builder has the luxury of absolute positioning - the sizes of buttons, fonts, etc., on the Mac can be expected to be fairly static. This clearly isn't true in Java, since we hop platforms. A Mac button is a different size than a Windows button. Heck, I can have different widget sizing on the same platform by hopping around the available look-and-feels - can anything intended for the Motif L&F look right in another L&F? That's why we use LayoutManagers, to express the relationship between widgets - that they're arranged in a certain spatial order or that some get extra space and others don't. Can a GUI present a LayoutManager effectively? I think so - I remember Visaj making even GridBagLayout feasible in a GUI tool.

Maybe the blocker is that even when unfrozen and laid out, the different sizes of widgets still afford a surprise factor, but this should be true of code-based layout too. Nothing is a good substitute for actually testing on the major platforms.

So, I don't really have a good answer. It seems like this would be a nice way to develop and deploy apps, and a lot of people have talked about it for a long time. But it still hasn't happened. What's the blocker?

Related Topics >>