Chris Adamson's Blog

Defrosting Java GUI's

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?

Comments

• IntelliJ 4.0
  Take a look at the next version of IntelliJ. It has a real nice GUI builder that simply saves all layout properties/widgets to an XML file that can be referenced later on; similar to what XCode does. This really helps to keep the Java code clean.

  Posted by: ryan on October 30, 2003 at 07:06 AM

• Developers assume Java GUIs are dead
  "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 think it's not happening because people aren't asking for it and they don't ask because they think the Java GUI is dead.

  I heard that the Netbeans team demonstrated a GUI builder that used XML serialization but we're still stuck with the "writing ugly code and making blocks uneditable" solution. Where did the better solution go?

  It's a shame really. We could be using Java for the next fifty years (think COBOL) - will we always think that Java isn't a good language for GUI applications?

  Ian

  Posted by: ifairman on October 30, 2003 at 08:48 AM

• Because GUI Builders suck
  There's two parts to the GUI builder problem. One is how do we deal with opening the built GUI later on. Using XML and either generating code from your build file or building the GUI on the fly takes care of that pretty well. The problem is where do you interface your business logic and event handlers with the GUI. Using listeners helps some of this, but registering them isn't easy if you don't have an actual static API to compile against. Perhaps we have something to learn from VB and Konfabulator here.

  The second is that there are no good visual editors for GUI code. It's not easy to visually represent and manipulate the various AWT layout managers. The solution to this, I think, is to not deal with all of the potential layout managers. Come up with one (or a few) completely visual ways of specifying layout that are easy to use and then create a layout manager that implements it (or hack gridbag to do it).

  As it happens I'm working on a visual editor which does exactly this.

  - Joshua

  Posted by: joshy on October 30, 2003 at 12:09 PM

• Re: Because GUI Builders suck
  Your first point can be solved by creating a class from your build file and letting the user extend from that; placing the right variables (buttons etc) as protected member variables in your generated class and you are left with a straigforward MVC pattern.

  The second point is half true; I know of one designer that is easy to work with and provides enough for about any use you will have for your GUI.

  Its nice you are working on a visual editor; please take a look at a project that exists for more then a year alread and is very mature in features and workflow.
  And yes; it provides new Layout Manager to solve the problems you seen.

  Posted by: zander on October 30, 2003 at 12:46 PM

• Re: Because GUI Builders suck
  Ehh; and that project is: http://uic.sf.net UICompiler ;-)

  Still waiting for a preview button here..

  Posted by: zander on October 30, 2003 at 12:47 PM

• Because GUI Builders suck
  In response to, "The second is that there are no good visual editors for GUI code," that may be true for Java, but there certainly are for other languages/platforms. A noteworthy example is Interface Builder.

  And it just so happens that IB and Cocoa conveniently addresses your other concern: How to interface your program logic* with your GUI. IB and Cocoa does a fantastic job of this.

  Before I began developing in Java 6 years ago, writing code to specify the layout of a GUI was an alien idea. I had tried Java GUI-builders (Visual Cafe at the time), but they, as this blog argues, took the wrong approach: generating code. And six years later, we're little better off.

  Layout managers pose a problem, but Java is well suited to the sort of GUI-to-program logic that Cocoa uses. Java and Objective-C are similiar in that they are dynamic and support reflection. Java just doesn't exploit this dynamism for building GUI applications.

  * PS, the term "business logic" is often overused. Program logic may not be the best term, but it more generally describes the concept.

  Posted by: jimothy on October 30, 2003 at 02:53 PM

• No every Java developer should be a GUI developer
  I'm kind of sick of people complaining about Java Swing and GUI packages.

  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.

  Layout Managers, the Swing thread and spatial ordering take time to learn and master. People jumping into Java GUI development are usually unprepared and get frustrated very easy at a widget that won't refresh, or a thread that makes the whole screen freeze. So they try to find a 'tool' to do the thinking for them. And when the tool doesn't do everything expected, people complain that Java GUIs are either unresponsive or don't look as pretty as native Windows (or Mac).

  I've been doing GUI development in Java for about 5 years now. I can tell you that my interfaces are clean and nice, with no thread blocking, and I don't need a GUI builder to do it for me. As for writing widget properties out to a file, I haven't found much use for that (not that is doesn't have its uses). I think the XML-to-widget translation might be more than most (not all) people are looking for.

  For anyone complaining that Java GUIs can't cut it, I suggest they hire a Java developer who knows how to write GUI code. They'll be glad they did.

  Posted by: jeremyzacker on October 30, 2003 at 04:38 PM

• Not every Java developer should be a GUI developer
  Yea, that should read 'Not'.

  Posted by: jeremyzacker on October 30, 2003 at 04:39 PM

• IntelliJ 4.0
  As far as I know the IntelliJ method is still a code generator, ie. compile time not runtime. The XML files are for the GUI builder itself, rather than the code.

  Posted by: brendonm on October 31, 2003 at 12:55 AM

• Sounds a lot like XUL
  There are several Java XUL implementations out there.

  Most support Swing, some support SWT, and a few can even render to either.

  Have a look at http://xul.sourceforge.net/ for more info.
  

  Posted by: ahornby on October 31, 2003 at 05:47 AM

• No every Java developer should be a GUI developer
  If you've done GUI development in other languages and platforms, you'd likely disagree that "Java makes it so darn easy."

  Before Java, my background was developing "classic" Mac (i.e., pre Mac OS X) applications. Back then, Apple provided a good tool for for visually laying out GUIs called ResEdit. But the event handling provided in the Mac APIs were rather horrible.

  Java's event handling, even the 1.0 model, is much better. But having to code layout is unnatural; the layout is inherently visual, so it is most natural to construct it in a visual manner.

  More recently, I've discovered Mac OS X, Cocoa, Objective-C, and Interface Builder. Play around with Interface Builder for half an hour, and if you don't say to yourself, "Wow, this is how GUI building in Java should be!", I'll buy you lunch. The concept of outlets and actions will blow you away. Unlike the existing Java GUI builders, this isn't some code generating wizard; it's just good stuff. You have to try it to really appreciate it.

  As I said in another post, there's no technical reason Java can't do the same thing. Cocoa and Interface Builder rely on the dynamism that Objective-C provides, but Java is also dynamic. But, first, developers need to break free from the notiion that GUI layout needs to be in code, and vendors need to realize that code generation is neither necessary nor ideal.

  So, I'd say one reason Java GUI apps are, in generally, so weak is that Java makes it so darn difficult to construct a decent GUI.

  Posted by: jimothy on October 31, 2003 at 06:15 AM

• Many of the technical blocks were removed in 1.4
  Your quote of the warning passage from the javadocs is from 1.3.
  The 1.4 docs advertise the new XMLEncoder/XMLDecoder as
  the recommended way to save java beans. (As you later say).

  1.4 provides much of the plumbing required to support tools
  that do not generate code. The technique of creating files with
  the "freeze-dried " widgets of a user interface is supported by the
  XMLEncoder/XMLDecoder. Interface Builder's "target-action"
  paradigm can be effected in 1.4 using an instance of the
  EventHandler class as a, dynamically bound, "connection" from
  widgets to an application's logic. EventHandler instances
  can be encoded as part of the design - as they are in "nib" files. Lastly,
  the SpringLayout layout manager, also new in 1.4, can be used to give
  a model of layout management that is reasonably natural for design
  tools to depict graphically.

  I'm also stumped as to why tools like Interface Builder have not sprung
  up for Java. At work, our teams, like all of the professional Java
  developers I've met, resort to hand coding their Java GUIs - which is
  slow and painful – all the more painful if you've used tools like
  Interface Builder in the past.

  Perhaps it's because 1.4 has not been out long enough? Maybe you
  need to have the GUI toolkit and the design tool written by the same
  company - as NeXT did. Or perhaps, as someone earlier said, Java's
  visual designers have been so bad for so long, people have just given up
  on them? Whatever the official reason for this madness, I wish someone
  would tell us!

  The new 1.4 technologies do work (with some tweaking). We've
  started a small project to show that it is, at least technically possible, to
  pull all the 1.4 stuff together to bring something like Interface Builder
  to Java/Swing - allowing people to create user interfaces without
  generating code. There's a preview of our efforts so far here:

  http://bob.twistedprotein.com

  We're very interested in feedback - particularly from the people who are
  sympathetic to the theme of this thread.

  Philip
  

  Posted by: milnep on November 02, 2003 at 03:17 PM

• There is a solution :-)
  Sounds like you're looking for "Foam".

  It has very easy layout management, avoiding all the old GridBag nonsense. Although I've only seen a short demo of Interface Builder, Foam is certainly more IB-like than traditional Java UI design tools.

  And, as you point out, XMLEncoder is an excellent way to persist designs. That's exactly what Foam uses!

  There are some demo movies and screenshots at http://www.computersinmotion.com

  it's great having one line of code do all your bean creation and layout :-)

  Posted by: gdperks on January 10, 2004 at 09:22 PM

This work is licensed under a Creative Commons License.