How should Java UI's be constructed?

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.

We do lots of dialog oriented UI's and have had to work quite hard to distill our coding style down to a very condensed format where we can express both UI and model bindings on one line of code (usually). This sets up the UI component, binds it to the model, and expresses what resource bundle properties to use for labels. It can also be combined with other helpers to do more advanced things like enable/disable panels based on checkboxes and things like that. We are using JGoodies FormBuilder as the main building block, and that alone saves a lot of work because of its solid and easy-to-work-with layouting.

Here's a typical example of how we set up a label+textfield and bind it to a JavaBean property:
builder.appendLine("theLabel", connector.connect("someField", new JTextField()));

The builder has a ResourceBundle associated, which it will use for finding "theLabel". The "connector" sets up property change listeners on a target Java object and also registers listeners with the provided component (a JTextField in this case). "connect" returns the components which allows for the condensed coding style, and also allows for chaining things (like "enable this field if that checkbox is checked) to it before adding it to the dialog.

With this in place I can do simple things easily and I still can do advanced things if I need to, without touching an XML file or generated code.

I worked for two companies where we built Swing GUIs and in the second company the president was very fond of UI builders (in this case visual age). For me it all comes to down to quality code and readability. Builders tend to be too fragile and too rigid, and in the long run don't always end up being quicker to develop. Other techniques like XML descriptions and such also tend to fit into this category.

I suppose however they will always be popular, just like most ORM tools will be. If you don't mind being forced into their way of doing it, they have value.

I agree with Rickard that the real benefits come from helper libraries that provide help when you want it and only when you want it.

I would like to mention Spring Rich Client, a project that has been around for a couple of years in the periphery of Spring (spring-rich-c.sourceforge.net/).

To me it is definitely a step in the right direction as it can take an object, create a model from it and create a form like builder.add("propertyName") and, via some XML, it is i18n-ed, it has type-specific binders, property-specific binders (it will recognise a date for instance or a percentage).

Validation rules can be created and the form cannot be committed before, only on commit would your object actually be modified so it is a doddle to implement cancel/revert etc...

I'm not a SpringRC developer by the way, just a happy user.
Learning curve is steep though...
I think it should be mentioned.

Benoit