Resource-Based GUIs Vs. Code Generators In Java

Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: 'Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well. Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.' Personally, I am partial to BuoyBuilder as a great solution to this issue."

Gee, what a deal!

[JanusFury (452699)]

300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing! That sure is cheaper than Visual C# Express, Interface Builder, SharpDevelop, wxWindows, Visual Basic, or any of the GUI builders available for Eclipse!

Wait, no, sorry. It's not.

Nice slashvertisement.

Re:Gee, what a deal!

[Mongoose Disciple (722373)]

Cost is irrelevant. Quality is the only measure.

That's the ivory tower answer, and from a certain perspective it's true and from a certain perspective it's not.

The last Java shop I worked in wouldn't pay for any development tools. Good tools that were free (as in beer) or close to it were at a premium.

Ivory Tower?

[shaneh0 (624603)]

If it were $3000 that would be an "ivory tower response." But $300? That's basically one days salary for a developer.

The Difference Between Theory and Practice

[anomalous cohort (704239)]

In theory, I'm not against the use of a GUI builder as long as it provides a way to use all of the layout managers that are available. I've just never seen one that could scale in complexity to the needs of a real world application. Sooner or later, the functionality requirements drive GUI elements to be created based on configuration settings and/or business rules. That is where you hit the wall with the GUI builder.

Re:

[zhiwenchong (155773)]

In theory, there is no difference between theory and practice. But, in practice, there is. - Jan L.A. van de Snepscheut

Sorry couldn't resist.

Re:

[misleb (129952)]

I don't know about other interface builders, but Apple's allows you to create as many GUI elements programatically as you want. It is can be a pain specifying and later changing the parameters for said elements, but you can do it.

-matthew

Re:

[TheRaven64 (641858)]

It's worth noting that Interface Builder is a really bad name for Apple's tool. It actually allows you to create serialised object graphs, which you can then restore later. This means that you can insert an instance of various controller classes in the same graph as the views. For document driven applications, it is typical to insert an entire model-controller-view graph into a single file, and restore a copy of it at runtime when the user creates a new window. This is a particularly useful way of worki

Re:

[by Anonymous Coward]

A good GUI builder will allow you to mix and match between resource-based controls and code-built controls. Interface Builder on the Mac is a great example of this. I can use it to build extremely nice and functional windows, but when I run up against the wall of what it can do then I am free to mix in code for whatever is necessary. Normally the code I have to write is small, and put together the whole thing is vastly simpler than laying out everything in code just so I can get a little more power.

XMLEncoder/XMLDecoder

[AKAImBatman (238306)]

Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime.

Anyone who's interested in this issue should look into the java.bean.XMLEncoder [sun.com] and java.bean.XMLDecoder [sun.com] classes. These classes are able to serialize and deserialize complete GUIs. In the past, I've used the Netbeans GUI Builder to develop throw-away GUI frontends, then serialized them to a file rather than using them directly. I then built a framework that used the little-known "Name" property on AWT/Swing components to attach actions.

The results were quite good. Not only was the GUI decoupled from the code, but development was actually accelerated as minor GUI hiccups had no effect on the rest of the codebase. The downside was that the XML occasionally had to be tweaked to perfection as the XMLEncoder class was not 100% perfect in serializing some of the finer details.

A few years ago I spoke with one of the Netbeans developers about making the XMLEncoder format the standard for Netbeans. The idea was met with some resistence, seemingly because there was no actual Java-standard framework to target. The JVM base libraries have the Encoder/Decoder routines, but all the rest of the work must be done by the programmer. (Such as attaching the actions to the components.)

Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

Train yourself to use Swing Actions. It seems like you're creating hundreds of little objects, but what you're really doing is encapsulating actual actions in the system away from their physcial controls on screen. So if you have a button, a menu item, and a toolbar item that all do the same thing, a single action can control all three widgets. This helps smooth out issues like keyboard shortcuts, which can get quite confusing when coding a Swing application.

Re:

[WinterSolstice (223271)]

That's a pretty good point.
I've run into issues like that with NetBeans in the past, and it was a serious headache - I never tried the technique you mention.

My biggest issue with Java GUI development, however, is that there is no common codebase for it - if I write a project with Borland JBuilder or whatever, I have to totally redo the GUI in NetBeans or Eclipse. At least, this has been true in my experience with Borland (which was short and negative). Xcode also has this issue.

Can we get something more lik

Re:XMLEncoder/XMLDecoder

[AKAImBatman (238306)]

Can we get something more like GTK or something with a nice cross-platform *standard* GUI toolkit?

The problem isn't the toolkit. It's the lack of a standard serialized form. In the Windows world, the standard format is known as a "resource file". Since all GUI editors target this resource format, there is no compatibility issues across IDEs. Similarly, GTK+ standardizes on GladeXML from the Glade Interface Designer [wikipedia.org]. So there's no question about what format an IDE should support when adding a GUI Designer.

Swing is one of the few GUI technologies that doesn't have a standard serialized format. The XMLEncoder technology took a step toward solving this, but didn't follow through. The result was that we had a format, but no library to actually wire up a deserialized GUI! (e.g. GladeXML is decoded by libglade) This oversight was rather massive, but ended up being ignored as the focus continued to shift toward server-size J2EE development.

Re:

[WinterSolstice (223271)]

So basically there is a format to use, but you're on your own to create the actual document? Like writing XML by hand, kind of thing?

-WS

Re:

[AKAImBatman (238306)]

So basically there is a format to use, but you're on your own to create the actual document?

Sort of. In my case, I serialized a running GUI to get the file. I could have hand coded it, but that would have been a pain. Instead, I created it in Netbeans, and ran the class through java.bean.XMLEncoder.

Again, the REAL problem is attaching the actions. (i.e. events, keymappings, etc.) If you think about it, you can't attach an event listener inside an XML file, because the XML file is decoupled from your code. S

Re:

[94west (957350)]

BuoyBuilder uses XMLEncoder/XMLDecoder. And it also lets you persist actions, so you don't need the glue code to set up actions after loading the UI. You can do this in one of two ways: (1) you can actually include the object that is the target of the action in the XML file (by making your class available to BuoyBuilder) or (2) you can provide a proxy to the object that will be the target, and provide the instance when loading the UI (or more properly the persisted object graph).

XStream

[MikkoApo (854304)]

I use XStream [codehaus.org] which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial [codehaus.org]).

Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design

Re:

[AKAImBatman (238306)]

I use XStream which is very nice xml serialization utility library.

I have played with XStream a bit. It's nice, but it has the disadvantage of (at least when I tried it) not being able to correctly serialize a Swing GUI. The Java Bean libraries are tweaked to understand Swing classes, so they correctly serialize the GUI in nearly all cases. (Minus a few of the fine details I was mentioning.) Deserialization is a minor issue in comparison.

he XML-serialization has a few problems though:
* Versioning, what if t

GINAC

[lieven_dekeyser (644644)]

We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code [ugent.be].

As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!

Re:

[fireboy1919 (257783)]

Okay! Here's some help.

You've joined the ranks of Mozilla Firebird, and Jetty, the Tads Virtual Machine [drizzle.com] by trying to make a new project with exactly the same name as an already existing, extremely popular project.

How about you rename it to something that isn't taken?

GINAC=>GINAC is not a computer algebra system [ginac.de]

Step #1 of picking a name for any OSS is looking for it on Google.

Re:

[julesh (229690)]

Step #1 of picking a name for any OSS is looking for it on Google.

Step #1 of naming *anything* is looking it up on Google.

Re:GINAC

[computational super (740265)]

You should just go the extra few feet and call it "Visually Activated GUI Is Not Application Code".

Huge oversight on Sun's part

[xtal (49134)]

I'm not sure how they released without some sort of GUI building tool. I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)

Re:

[_xeno_ (155264)]

There's Netbeans [netbeans.org] which has a GUI builder. (Which, IMHO, sucks. Or at least did the last time I used it.)

Eclipse [eclipse.org] also has plugins (the Visual Editor) to allow creating GUIs graphically. (Which is, IMHO, worse than Netbeans's.)

So, there are GUI building tools. They just suck. (IMHO, of course.)

Personally I'd like to see something like XUL where the GUI is specified using a markup language. Which is why I started writing one and then never released it.

Re:

[chroma (33185)]

Take a look at the videos that demonstrate Netbeans 'Matisse' GUI builder. I use it all the time, and find it quite handy:
http://www.netbeans.org/kb/articles/matisse.html [netbeans.org]

Re:

[Eric^2 (33085)]

Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)

Yes [jformdesigner.com]

It supports many layout models [jformdesigner.com] including the JGoodies FormLayout, which is far superior to the old GridLayout system.

I've been using it for the last few years and it works marvelously.

Re:Huge oversight on Sun's part

[VGR (467274)]

I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.

I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.

Sun has tried [sun.com] three [sun.com] times [sun.com] to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).

I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.

A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.

Faces in the Crowd

[Doc Ruby (173196)]

Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.

If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.

Java could increase its stature among distributed architectures. And make our lives easier.

Re:

[tcopeland (32225)]

> Possibly Java's greatest strategic feature is the classloader
> that can dynamically retrieve classes across the network
> at runtime and safely instantiate them.

It's kind of interesting how this feature conflicts with Java's static typing system. I mean, if you're receiving a bytestream across the network you need to have some sort of way to unmarshal it into objects, and doing that in Java involves a fair bit of casting and exception catching. You see the same sort of issues with XML to object

Re:

[Doc Ruby (173196)]

Typing the incoming class doesn't seem to be a big problem. Maintaining consistent namespaces can be a problem, but that's a reason the classes have a single namespace ensuring global uniqueness and identity, <FQDN>.<FQCN>. Why cast to a type, when you can just use the original type, called by name to the classloader?

Never heard of Matisse eh ?

[by Anonymous Coward]

Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators.

Whenever it comes to Java it always amazes me how many people have very outspoken opinions about it while its almost immediatly obvious that they hardly know what they're talking about. Then again, when reading the article its becoming obvious that when he's talking about GUI's (since when do you code in a GUI? I use an IDE for that) he actually means to say Eclipse. Don't get me wrong: I'm not dissing Eclipse here, but do question his bias.

When it comes to building GUI's Java really allows itself to be used by code generators IMO simply because Java is very modulair build. The only problem you might face here are the somewhat limited layout managers. For the non-Java people amongst us: these basicly define the "interface" between the GUI you're building and the way it behaves. For example; when it comes to resizing or placing of the objects then you're dealing with a layout manager.

Now... When it comes to Java IDE's two names immediatly spring out: NetBeans [netbeans.org] (my personal favorite) and Eclipse. Now that he has commented on the latter let me comment on the first. From NetBeans 5.0 and up it comes with a fancy GUI builder codenamed "Project Matisse". Its official name is now NetBeans Swing GUI builder [netbeans.org]. After taking a closer look at that I wonder if he still thinks that there are no decent GUI builders available for Java.

The real problem here isn't so much the GUI builder but the underlying layout manager which needs to keep things in check. I think that also explains why there isn't much of this available as it looks to me as if there aren't many people about who manage to come up with decent Java coded tools which can be used and adopted by many other coders. NetBeans has solved all this by introducing a layout manager of their own, the so called Absolute Layout. Pro's are its extreme extensiveness, the con's are that if you wish to use it you'll have to ship it with your software because its not part of the standard Java Runtime Environment (JRE).

If you wish to see a demo of Matisse in action then check out the NetBeans flash demos [netbeans.org], especially the first part of "Why NetBeans?". Personally I'd recommend another approach, namely simply downloading NetBeans [netbeans.info] and trying it out for yourself. Its available for Linux, Solaris, Windows and I think even OS X.

Re:

[mark-t (151149)]

Uhmm.... Matisse sucks. I like netbeans... but I really do hate their GUI builder.

The GroupLayout that they have bundled with it seems to crap out all the time, as previously placed components suddenly go zooming off to one side. or sometimes even out of the bounds of the component entirely, when all I did was add one more component to the parent. The number of headaches this has caused me in the past is enough to make me not even _try_ using it anymore... I now almost always use either gridbaglayout o

Interface Builder

[David Off (101038)]

> Apple has had this for years with Interface Builder

Presumably NeXT has had it for even longer, a couple of decades or there abouts. IB was written by a brilliant French coder as I recall... he was a friend of a colleague. Short of firing up my NeXTBox does anyone remember more of the history?

Re:

[0racle (667029)]

No, but like many things, you only need to know where to look [wikipedia.org]:

Interface Builder first made its appearance in 1988 as part of NeXTSTEP 0.8. It was one of the first commercial applications that allowed interface elements (such as widgets and menus) to be placed in an interface using a mouse.

Re:

[David Off (101038)]

Yes but they don't say who the author(s) is.

Anyway I was right about the French connection Jean-Marie Hullot [rixstep.com] and Bertrand Serlet [wikipedia.org] are the authors. Bertrand worked at Inria in the offices next to mine when I was an engineer at the OSF. It is interesting that Simon Patience is director of Engineering at Apple and also worked in the same office block in downtown Grenoble city. I believe their are others too.

Re:

[David Off (101038)]

> I know at least Visual Studio 6 had a GUI dialog editor.

It did. IB was a steeper learning curve but built nicer looking (at the time)and more robust interfaces. The Visual Studio GUI builder produced some really messy code as I recall - but I haven't used it since 1993.

Just Use Swing

[mrcparker (469158)]

XML-based Swing GUI tools are really a dime a dozen, and always seem to add an extra layer of complexity to Swing-based apps. Swing is a really nice component system, and pretty much every object is easily extendable. Personally, I have tried a good deal of the XML-based systems, and really using Swing as it was intended is the way to go. Build your own components, extend them, combine them. I know that there is this idea that you hand over the frontend to a designer, but we all know that most of the time it is the developer hacking on the frontend.

I can understand why people think they need XML-based systems. So much Swing-based code sucks ass. Putting all of your buttons and frames in a big-ass method is nasty and hard to maintain. Well-thought-out componentized Swing code is easy to maintain and nice to look at. Plus, once you are finished with your project, you can re-use any components you built. Swing is a great library - more people need to just learn it.

Apache Velocity

[Roy van Rijn (919696)]

I've been developing a lot of applications lately with J2EE (thus Webbased). There are some cool things happening there, for example good integration with JSF and Dreamweaver. This lets designers use Dreamweaver while the programmers are programming the back-end.

Also one thing that might be worth looking into is Apache's Velocity, templating at a whole new level.

Glade

[RichiP (18379)]

The Java-Gnome Project [sourceforge.net] uses Glade [gnome.org] to build a serializable (to XML) GUI.

Hand coding GUIs

[hey! (33014)]

I see nothing wrong with this.

Hand coding may not promote a clean separation of concerns, but it does nothing to preclude it. Interface generation does not ensure a clean separation of concerns. In fact I doubt that it does anything significant to promote it.

The problem is that the controller tier is still a user interface component, which many engineers don't seem to understand. The achilles heel in most MVC programs are bloated, unmaintainable controllers. You still end up with important assumptions

Re:

[hey! (33014)]

I can sympathise with what you're saying.

I think part of my point is view/controller integration, while not ideal, is not that huge a problem, because they are both user interface elements. What's a big problem is the failure to abstract business domain logic. Whether or not you put it in a "model" tier is mere quibbling. It doesn't matter, as long as its not in the UI. Compared to that the gains of decoupling the view and controller are modest.

That's why I would prefer a solution that does not store t

IntelliJ

[sproketboy (608031)]

IntelliJ's designer does exactly that. I saves the UI code in XML files and you only need to code the specific business logic in a seperate class. The designer itself is quite nice as well.

TrollTech's Jambi does this quite nicely

[yerM)M (720808)]

It can be used opensource (GPL) as well as commercially. Here is the link to the tech preview. [trolltech.com]

I have to say, I'm pretty impressed so far.

Serializing GUIs is difficult?

[bill_kress (99356)]

I've always wondered why simply serializing a GUI wasn't used more in Java. Perhaps because Swing is so easy to use. Most java programmers I've known in the past shunned any type of GUI development tool in favor of hand-coding swing because it's so much more straight forward.

Also, it's difficult to get reuse out of a GUI editing tool, but very easy to get it by hand-coding. I generally write factory-type code that handles generating menus, buttons and linked Actions together, in a GUI tool you will often

ResEdit

[johnrpenner (40054)]

it was in 1984 that we already had ResEdit [wikipedia.org] which abstracted the whole GUI from the code -- it did such a good job, that end users could open a shipping application executable, and go in and change bitmaps, menu keyboard shortcuts, dialogue texts, and sounds -- so long as they kept the same resource ID, the app would keep on working.

this system was eminently useful in getting mac applications translated into languages other than english, as any user could open the shipping application with resedit, start tra

having trouble digesting this...

[geekschmoe (244913)]

Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

I don't mean to sound all high and mighty, but if you aren't a disciplined coder, then you're not very serious anyway. You can pre-plan the MVC design to your hearts content, but it takes discipline to stay within the boundaries of the original design. Especially since if you don't then you create one of the worst anti-patterns ever, making you wish you'd just written one monolithic chunk of procedural code because bugs/changes would be doable.

Re:

[Doctor Faustus (127273)]

A proprietary XML format that happens to be somewhat easier to read than a proprietary binary format is no less proprietary.
Perhaps not in a legal sense, but it's a hell of a lot easier to reverse engineer.

Re:

[iluvcapra (782887)]

A proprietary XML format that happens to be somewhat easier to read than a proprietary binary format is no less proprietary.
Perhaps not in a legal sense, but it's a hell of a lot easier to reverse engineer.

Also, you can check an XML GUI source into an SCM, and then have a chance of merging and diff'ing it, which is impossible with the binary formats (my one serious gripe over interface builder).

Re:

[chochos (700687)]

Subversion can diff binaries, so it's not impossible. Also, as a sidenote, I remember a CLI tool that could read a NIB file and spit out a text file describing all its contents. This text file could be used to generate another nib file, so it was very useful when upgrading between incompatible versions of IB, and maybe it could be used to store release versions of NIB files in CVS.

Re:

[twehrle (580963)]

Anyone writing internal applications that want a rich user interface. Not everyone writes blogging/email/im/forum/newsfeed software.

Re:

[VGR (467274)]

Maybe I'd like my application to have a menu bar which can be navigated with the keyboard.

Maybe I'd like drag-and-drop of files or images or custom data.

Maybe I don't care for the cardinal UI sin of having scrolling areas inside other scrolling areas.

Maybe I want a context menu.

Maybe I want something HTML doesn't provide, like a table with selectable rows.

Maybe I don't want to worry about disabling the "Back" button.

Maybe I don't want to worry about a user double-clicking a form submit button.

If UI librarie

Re:

[nacturation (646836)]

No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.

Right on their home page:

"BuoyBuilder(TM) is released as Open Source under the OSL license. Royalty-free, commercial licenses are available for purchase."

http://buoybuilder.com/DownloadData/BuoyBuilder-sr c-1.1.zip [buoybuilder.com]