Declarative UI for Swing? Why not?

[Alex Konshin]

Have you ever thought about implementing storing/loading of Swing UI from XML similar to what is done for SWT in XWT?
As I understand it would be much easier to implement than parsing Java code.
If it would be done than it would be possible to mix composite components designed and saved in XML with generated Java code. I guess that you can reuse a great deal of XWT implementation for implementing this feature. XML schema would be similar to XWT. It would also theoretically provide a way for converting XWT<=>Swing XML.

[blombar]

You should take a look at CookSwing at http://cookxml.yuanheng.org/cookswing/. This may be what you are looking for.

[Alex Konshin]

You should take a look at CookSwing at http://cookxml.yuanheng.org/cookswing/. This may be what you are looking for.

I have seen this tool but
1) I was under impression that the project is dead
2) It has no UI designer.
3) Looks like it doesn't support GroupLayout. At least I don't see it in the documentation.

You right, that project is very close to what I think of but it doesn't have all features that I want. The idea of such feature is obvious and I have seen it in some other projects but niether of them has all required feature.
I think WindowBuilder already has most parts. It already has support for XWT. Then I think the next step should be to add similar feature for Swing.
It is very pity that Sun rejected declarative UI project.

[Eric Clayberg]

Have you ever thought about implementing storing/loading of Swing UI from XML similar to what is done for SWT in XWT?

We would only do that if Oracle/Sun added full support for it to the JDK or if some XML-based API became a de-facto standard in the Swing world. I don't see either happening any time soon.

Personally, I don't see much benefit to XML-based UI's. The XML API becomes, in effect, just another language you are trying to interface with Java...often with a considerable impedance mismatch and the added slow-down of an extra layer (unless the XML code is compiled directly to byte code). For anyone even marginally familiar with Swing, you aren't likely to gain any better readability, and for anything even modest complex, XML often runs out of steam pretty quickly (leaving you with the least common denominator), and you end up resorting to Java code anyway. I'd much rather focus on generating well formatted, easy-to-ready Java/Swing code as we do already.

[Alex Konshin]

We would only do that if Oracle/Sun added full support for it to the JDK or if some XML-based API became a de-facto standard in the Swing world. I don't see either happening any time soon.

Yes, Oracle/Sun aborted such project and as I understand their plans they will be busy with 1.7 development for next few years. It means that in nearest future they will not come up with such standard. From the other hand, if such standard would be implemented in WindowBuilder and Eclipse 4 (e4) then it has a good chance to become a de-facto standard.

Personally, I don't see much benefit to XML-based UI's. The XML API becomes, in effect, just another language you are trying to interface with Java...often with a considerable impedance mismatch and the added slow-down of an extra layer (unless the XML code is compiled directly to byte code). For anyone even marginally familiar with Swing, you aren't likely to gain any better readability, and for anything even modest complex, XML often runs out of steam pretty quickly (leaving you with the least common denominator), and you end up resorting to Java code anyway. I'd much rather focus on generating well formatted, easy-to-ready Java/Swing code as we do already.

One of the obvious benefit is separation of code from meta data as UI declaration actually is. Then it would be possible, for example, to store/load UI components/forms the same way as data.

It also would simplify splitting tasks between developers (one could be responsible for representation UI while another implement business logic). Well, you might say that it can be done now by changing Java code but please note that any changes in Java code lead to reintegration, retesting and redeploying of the application. But in fact you just changed meta-data. If, for example, your UI is driven by data structure than it doesn't make sense to rebuild application if that structure is changed.

Another benefit would be unifying usage of Swing and XWT in Java code. Theoretically I don't see any problem for GWT to join this list. If all forms would be loaded from XML and bindings are established the same way for all these frameworks then Java code might be the same. As result this feature might really make Java GUI application become "write once run anywhere".

[Eric Clayberg]

if such standard would be implemented in WindowBuilder and Eclipse 4 (e4) then it has a good chance to become a de-facto standard.

It's not the place for WB to implement any new APIs like that. I don't see such a standard emerging from Eclipse either (for example, I don't see any significant adoption of XWT by Eclipse.org projects).

One of the obvious benefit is separation of code from meta data as UI declaration actually is.

I view GUI classes as being first class components of an app just like the data model (subject to refactoring, inheritance, etc.). While the UI might be considered meta data in some apps, I don't see that being the general case. If your UI is truly data driven, then there isn't much of a need for a GUI builder, and you probably aren't even using Java to define your data model.

It also would simplify splitting tasks between developers (one could be responsible for representation UI while another implement business logic). Well, you might say that it can be done now by changing Java code but please note that any changes in Java code lead to reintegration, retesting and redeploying of the application. But in fact you just changed meta-data. If, for example, your UI is driven by data structure than it doesn't make sense to rebuild application if that structure is changed.

Again, if your UI is driven that way, you might as well just have your UI generate itself dynamically and dispense with the GUI builder entirely. I also don't buy the argument that it will simplify splitting of any tasks...or at least I have never seen this done successfully. In most apps, it is very likely that any change to UI will require changes to the application logic as well. In that case, there is a lot of benefit to having the UI and the app logic all written in the same language and supported by the same tools (like the Eclipse JDT).

Another benefit would be unifying usage of Swing and XWT in Java code. Theoretically I don't see any problem for GWT to join this list. If all forms would be loaded from XML and bindings are established the same way for all these frameworks then Java code might be the same. As result this feature might really make Java GUI application become "write once run anywhere".

I've seen lots of XML-based UI APIs, and they all suffer from the least-common-denominator problem. SWT, Swing and especially GWT have some significant differences that would be difficult for any XML API to capture. Defining your Java application UI in Java means that you have the full power of Java available to you. Defining your app UI in XML limits you to the subset of UIs that the XML API is capable of supporting (which is often quite limited).