Java: GUI Alternatives

The problems

After a little experience, it isn't difficult to build a Graphical User Interface (GUI) in Java, but it is hard to get something that is easy to maintain and is flexible. Many styles of GUI programming simply don't scale well.

Separation of concerns

• BAD: Mix logic and interface. This is a typical style for small student programs. The code to perform the action of a button is in the button's action listener. This does NOT scale well as programs get bigger.
• GOOD: Separate GUI from logic. As programs grow larger, it's essential to separate the GUI interface processing from the logic. This is easy to do by putting the interface and logic in separate classes. Some GUI generators below help accomplish this.

Some GUI programming alternatives

1. Use Drag and Drop GUI editors. Many IDEs (NetBeans, Eclipse (only SWT), JBuilder, ...) have GUI editors and there are also numerous standalone products. They don't always enforce separation of interface and logic, but it's usually easy to do. I've used NetBeans with good results.
2. Alternatives to Swing and AWT. You don't have to use the Java GUI libraries to build your GUI. There are alternatives.
   • SWT - () - IBM's alternative that produces a more native-like appearance and higher performance, at the expense of portability. Opinions vary on how well SWT accomplishs its goals.
   • Bouy - (buoy.sourceforge.net/) - A public domain alternative. This looks very nice, but I haven't taken the time to try it out yet.

     "Buoy is a library for creating user interfaces in Java programs. It is built on top of Swing, but provides a completely new set of classes to represent graphical components. It offers many advantages over using Swing directly, including:

     • A much simpler, cleaner, and more consistent API
     • A better mechanism for laying out interface components
     • A far more powerful event handling mechanism, which is based on dynamic binding of arbitrary methods as event listeners
     • Built in support for serializing user interfaces as XML, then reconstructing them again

3. Use Flash or JavaScript+HTML for the GUI. Why should your interface be in Java? You can use existing GUI technologies like Flash or JavaScript+HTML (check out Sun's LiveConnect, which should already be installed with your version of Java) to interact with your Java program.
4. Describe the GUI in some other language (eg, XML). This approach is described below in the XUL (XML User interface Language) philosophy.

The XUL philosophy

Everyone says that interfaces should be separated from the logic of the program, and one of the most promising approaches is to represent the GUI in a markup language (think HTML forms with a full set of widgets). The Mozilla XUL group (see link below) has been one of the most active in proposals in this area, altho the actual offerings don't seem quite ready for prime time. Some good links to start with follow.

• XML User Interface Language (XUL) Links (xul.sourceforge.net/links.html)
• JDesktop Network Components shows that Sun is thinking about these issues.
• XUL News Wire has links to a lot of approaches.

I've tried SwiXML and Thinlet, both of which read an XML file to build the GUI at execution time. On small test programs I really liked them. They're not quite mature yet (eg, weak documentation). I'm currently evaluating Swixml.

Take a look at XUL and Java. It seems obvious to me for some comments by Karsten Lentzsch of JGoodies for some criteria that might be used in evaluating this not-entirely-obvious technology.

Microsoft has announced XAML, an XML description of user interfaces (and much more) for the upcoming "Avalon" system (see below). It looks like Microsoft may take the lead in this area; and I wouldn't be surprised if their work sets the future direction. Java's Java Desktop Network Components (JNDC) (see www.javadesktop.org/articles/JDNC/index.html, Java Desktop Network Components) shows some philisophical interest in XUL.

XUL based and other GUI generator schemes

I didn't look closely at most of these, but this gives the idea that a lot of people would like to make this work. My goal is to find something that makes simple programs simpler, ie something for student programs. Some of these frameworks may be very good for simplifying large programs, but

There are related efforts, such as

GUI Editors

Alternatives to Swing

Altho Swing (or the older AWT) is the standard for a Java GUI, there are alternatives. These alternatives exist because some are smaller and/or faster than the very general, but large and somewhat sluggish Swing library.

Another approach

UIHierarchy tries to capture the hierarchical nature of layouts by providing classes that reflect this nicely. Has links to similar efforts.