Java Enterprise Architect, open source and Linux fan. Jacek has posted 11 posts at DZone. You can read more from them at their website. View Full User Profile

Taking on GUI Builders with the Swing JavaBuilder

  • submit to reddit
Now let's take this baby out for a spin and see what it can really do.

 Upon running the app, we should see:


 Notice that the layout is created, all controls are aligned by baseline (thanks to the wonders of MigLayout) and even the Save and Cancel buttons are the same size (all of this possible to our MigLayout DSL). Also, thanks to databinding the Person's first and last name have been progagated from the Java class to the UI automatically.

Let's enter an invalid email address and press Save:

The integrated validation checked the input against the email validator in Apache Commons Validators and automatically displayed an error msg to the user.

Let's enter a valid email:

and press Save. The Save button was wired to execute the save() method on the Java side (via the "onAction=save" section in YAML), which in turn was flagged as a method that should be run in the background using Swing Worker (with an integrated progress bar and a Cancel option, if required):

 After successfully saving, the done() method is invoked that displays the person's data. Please note that the email address we entered in the UI was automatically propagated to the Person bean via data binding:

We can now press Cancel. Since the YAML file requested a confirmation using the global "$confirm" commmand before executing the cancel method:

- JButton(name=cancel, text=button.cancel, onAction=($confirm,cancel))

we get a standard confirmation prompt:

In total we have a perfectly working typical business application with integrated control creation / layout management / data binding / Swing Worker support / input validation in less than 25 lines of YAML and with a Java class where most of the logic is purely business-related and has little, if any, UI-specific code in it.

I hope this little example will get you interested in the Swing JavaBuilder. For fans of other GUI toolkits, we have some early dev builds of the SWT JavaBuilder and some work is being done on the GTK+ JavaBuilder (which will use the Java-GNOME bindings to allow building of native Linux apps with Java).

Cheers and happy (productive) building!

P.S. You can view the source files for this tutorial app in our GitHub repository:




Published at DZone with permission of its author, Jacek Furmankiewicz.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Alexandre Navarro replied on Tue, 2009/03/31 - 6:41pm

I used SwingJavaBuilder for a POC (proof of concept) in my firm because I needed to rewrite a GUI quickly and we have a huge debate on productivity to make GUI in Java (by the hand or with Matisse) versus C# with Visual Studio.

 I made some GUI in java by the hand or with Matisse and C#  (I'm not an GUI expert) before and I tried after SwingJavaBuilder (it seems to be interesting).

 And honnestly, after use it, I can't use another framework to make GUI anymore.

Why? I will try to explain in 5 points :

1) Productivity : if you type quickly, you write faster than drag and drop a GUI Builder after 2-3 hours of learning (and also by the hand).

2) Maintenability et powerfull: thanks to the VDSL of Swing Java Builders above MigLayout, the killer feature of Swing Java Builders, you can write easily a complex GUI (not really possible with Matisse Builder like) and maintain it easily (not really possible when you write GUI by the hand).

3) Concise View : the view in yaml is so elegant and concise, not verbose like xml, not }}}}}}}}}}}}} like JSON or java by the hand. I rewrote a Panel from java by the hand with miglayout to Swing Java Builder. The code of the view has passed from 500 lines (in java) to less than 80 (in yaml). It also force to separate View (yaml) from Controller (java).

4) IDE Independance : who writes a GUI in IDE and have a lot of problems when he wants (or was forced) to change the version of IDE (VS2003 -> VS2005) or IDE (JBuilder)? Me, maybe you?

5) Extensible : Java Builders uses the others frameworks like beansbinding, commons-validator, miglayout (also SWT and jface if you prefer, maybe a day above JavaFX or GWT or a web framework). If you want to write a part of your GUI by the hand, you can (not really possible with Matisse Builder like). There is also a project with some extentions Swing Java Builders like SwingX, Jide or MyDoggy (

For these reasons, in my firm (an famous Investment Banking), we decided to rewrite a Real Time Trading Application from C# WinForm (VS 2003, difficult to migrate to VS2005) to Swing Java Builder, we are happy with it.

Try it, you will adopt it and you will not waste time to write and maintain GUI.

Alexandre Navarro

 PS : Thanks to Jacek who writes an amazing GUI framework with a lot of innovative ideas (yaml for view, VDSL above miglayout for layout ...)

Jacek Furmankiewicz replied on Tue, 2009/03/31 - 8:56pm

Thank you for your kind words, Alexandre.

But a huge part of of the benefits is owed to the amazing work Mikael Grev did on MigLayout. I was originally planning to support the base JDK layout managers, but after trying to come up with a sane, understandable way to use GroupLayout I realized it would be pure madness and destroy all the productivity gains I was hoping for.

And so my search for an alternative began. Once I discovered MigLayout I never looked back.

Including MigLayout in the JDK would allow Java to leapfrom past every other GUI toolkit out there, it is light years ahead of anything I've seen not only in Java, but in .Net and Flex as well. I hope Sun gets it included for Java 7, but somehow I am not optimistic.


Fred Swartz replied on Tue, 2009/03/31 - 10:44pm

SwingJavaBuilder is a great tool for making GUI coding MUCH easier than anything else I've seen.  For example, NetBeans Matisse can be nice but I've had to start over after a lot of work when Matisse got confoused.  And what's going to happen to future support of Matisse if IBM merges NetBeans into Eclipse?   Matisse may not be a bad choice, but it isn't quite as nice in practice as in theory.

 I've been a long-time Java GUI coder, irritated by the excessive verbosity of listeners, struggling with various GUI code structure philosophies, and cursing the horrendous Java layouts.   Eventually I accepted the verbosity and figured out an organization that worked reasonably well, and after trying some other grid based layouts decided to write my own.   The best grade one could give to Java for its GUI facilities is C -- everyone knows it could be much easier.   There is some serious pain here.

 I don't remember what it was that got me to take a look SwingJavaBuilder a couple of versions ago, but once I used it there was no turning back.   All new code uses it, and older programs that need major GUI changes are rewritten in it.   It uses a declarative style (think HTML table layout with a more compact notation) to describe the GUI, which eliminates a LOT of code.  This is due in no small part its use of MigLayout (a grid based layout).   SwingJavaBuilder then uses reflection to wire together parts of the declarative description with Java code for variables and listeners.  This moves the coding from a dull C to a bright B+.   Most of the pain is gone!

 With all this enthusiam, why wouldn't I give it an A?   The part that's missing is the "application framework", another area that Sun has really screwed up.  The Swing Application Framework (JSR 296) is in a usable, but lamenably incomplete and unsupported state.   I've never tried the NetBeans platform but have no wish to be tied to it.   With a simple, usable, portable application framework I would really be happy.   Perhaps that will remain outside the scope of SwingJavaBuilder, but I hope such a framework becomes available that can be nicely integrated with it.   Until then I'm doing OK with SwingJavaBuilder and my own simplistic application framework.

 You might want to try it. 

Thierry Milard replied on Tue, 2009/03/31 - 10:57pm in response to: Jacek Furmankiewicz

Jacek, thanks for the Swing javaBuilder. It is cool .

It is so bad Swing javaBuilder has not come 4 years ago. It seems it targets so much to the relativelly poor learning curve of Swing. People have had the feeling in the past "Swing was to complex" perhaps because there was not such a "simplefier framework" like "Swing javaBuilder". It should defenately ease the pain of Swing beginners.

MigLayout :  I just google it and read the cool introduction. It is just marvelous. Even after 10 years of swing codind I still find JDK layout managers ... just not obvious. On the opposite,  MigLayout ...I just needed 15 minutes of reading to understand the few (but powerfull) principles of MigLayout. I am so eager to just replaces the tens of differents JDK Layout by this MigLayout ! If only Sun Management could understand this ... it would be cool.

PS: Well Jacek, we never know about those Americain Sun managers ; After all it took them 4 years to understand jre was far to bulky ["briks and chains" ;) ] but they finally got that point and made possible the 1.6.0_update_10 _12 _14 series ... a bold move. It takes them time ... but ....never say never.

So I would not be so pessimistic about MigLayout : It does simplefies the developpement. Simplefier dev, means broader audiance. and oops ... more money.  They catch this, don't they ? 




Jacek Furmankiewicz replied on Wed, 2009/04/01 - 6:43am in response to: Fred Swartz

Personally, for me a framework is something like Java EE5, Spring, Wicket, etc.

I always envisoned Swing JavaBuilder as a library that is used in the context of some other framework above it, just like Apache Commons. It's supposed to be easily integratable into existing apps without the need to rewrite any existing portions of the code.

I think between Netbeans RCP, Eclipse RCP (and now Eclipse Riena) there is plenty going on in the in the GUI framework space...

Witold Szczerba replied on Wed, 2009/04/01 - 10:22am

Take a look at Google Guice. I know it is a generic, but I think as of now - perfect solution to glue the Swing application. I know this is not something like application framework, I am pretty sure the real app frameworks (like tragic SAF) should use IoC provided by libraries like Guice.
Still - it makes entire application much better organized when collaborators are being injected (not looked up), so there are less dependencies between components, as every one cares only about the other one which it directly needs.

Jean Said replied on Sat, 2009/04/18 - 7:52am

DISCLAIMER: I had never used any yaml stuff before

I had a look at Swing javaBuilder and I was both impressed and horrified. Impressed because it makes building a simple swing app even simpler, horrified because its yaml is absolutely impossible to debug. The parser mumbles unintelligible stuff that is totally useless and, there seem to be no structural validation. When it does not work, it seems like you have to rewrite your file from scratch or from another yaml. When I tested it on one of projects, I was screaming "please, make the damn file an xml one so that I can validate it".
After the deeper look at the situation I figured out that the parser does not support tabulations... it was such a pain only to discover this.

So, yeah, it will become great if some high level validation of yaml files is implemented, until then, I would not advise anyone to use this unless you're a yaml guru.

Robert Weber replied on Wed, 2009/04/22 - 10:18am

Before using JavaBuilder, I had never used YAML -- much less heard of it. However, the use of YAML as the model markup language should not be a deal breaker. In all honesty, you just need to RTFM.


I believe it was printed quite conspicuously in the PDF book (and this article IIRC) that you should NEVER use tabs for spacing in your YAML files. Aside from that, just attend to the guidelines and follow the examples given, and you should be golden.


By the way, even if you are a YAML guru, that knowledge won't even necessarily help. For one, the YAML syntax used in the model descriptors is a "compact" form of the YAML syntax. Also, the YAML used is just one particular grammar. You can draw a comparison in the XML world. For instance, between XHTML and a SpringFramework applicationContext.xml: you might know XML inside and out, but knowledge of how to build an XHTML file does not necessarily mean that you know squat about building an application context file. They both use XML, but they each use their own XML grammars.


By the way, I love JavaBuilder. I recently utilized it to build a configuration front end, and aside from some idiosynchrasies in the ClienObjects library (I didn't want to "bean up" my model objects) and my inability (so far) to meaningfully describe a JList in the YAML (notably bindings and actions), I am sold on using the JavaBuilder library on all new future Swing projects I encounter.

Jacek Furmankiewicz replied on Tue, 2009/04/28 - 10:25pm

It says in big block capital letters in the PDF book: YAML is based on WHITESPACE indentation and does not support tabs.

XML sucks. Period.

Jean Said replied on Sat, 2009/05/02 - 8:02am

I don't care that it is in the manual. The parser should throw a meaningful error when in encounters a tab. The simpler the error, the clearer the message. And high level parser should perform validation. Furthermore, the yaml eclipse plugin should have used spaces to indent

In the end, it does not really matter to me anymore since I've written my own xml based lightweight swing builder library since my first message. I'll probably open source it too. When SwingJavaBuilder will perform understandable validation, I will use it.


And please, it's not about sucking or whatever it's about validating possibilities. Sure you can tell whatever you want about xml grammaries, but when it's clean, well, it's clean. It surely cannot be as clean as yaml, but java xml parsing libraries are mature.

Neither do I care about xml being more verbose if it can be easily validated and verified. Dude, we're talking about professional stuff, not "bah, it sucks" or "it's evil, don't use it". If I lose time creating my exact file and debugging it, I have no interest in it.

SwingJavaBuilder could use an external syntax validator or whatever, but it clearly needs validation.


But it's promising, definitely.

Milind Rao replied on Fri, 2009/05/15 - 1:54am in response to: Jacek Furmankiewicz

Jacek, it looks very good. But I'll never use it.

I have had a torrid time with debugging Python code because of indentation. And years ago JCL code on the mainframe. Who cares about multiple closing braces? As long as it I get compiler errors and a good editor will match bookends, it doesn't matter. The fact that Tabs don't work and I don't get compilation errors, is just asking for trouble. There is a reason why we are Java developers - not python. Not that there is anything wrong with being a python developer - it's just not my cup of tea.

As far as I'm concerned, any language dependent on white spaces sucks. Period.

Jean Said replied on Mon, 2009/08/03 - 11:07am

Good to know more and more validation checks are added to Swing JavaBuilder, Jacek. I'll probably have a second look at it soon :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.