James Williams' Blog

This is an reasonable approximation of the Painter Demo implemented using my Summer of Code project, the Groovy SwingXBuilder. It’s not a pixel perfect port since I used a different LayoutManager, namely MigLayout. The amount of options makes it a little overwhelming at first but I found it easy to tweak components.

Note: This is a WIP and thus not feature complete. Not ready for prime time yet.


This is not the full Painter demo. The glowing shield and wooden area are images. The following code shows how the compound painter was constructed for the header panel:

 def compoundPaint = swing.compoundPainter() {
    mattePainter(fillPaint:new Color(51,51,51))
    pinstripePainter(paint:new Color(1.0f,1.0f,1.0f,0.17f),spacing:5.0f)
    glossPainter(paint:new Color(1.0f,1.0f,1.0f,0.2f),position:GlossPainter.GlossPosition.TOP)
}

Using the builder cut down the lines of code from 441 lines in the Java version to 127 in the Groovy version. Most of that reduction comes from combined declaration and layout.

Download the Netbeans project here.

You must read Filthy Rich Clients by Chet Haase and Romain Guy. I really think the subtitle should be the definitive guide to Swing. I’m only about 1/6 of the way through it and already have gotten dozens of ideas. Each chapter has several little examples that each spawn an "A-ha" moment. Chapter 19, my favorite, takes you through the process of designing the UI for Aerith with scans of scribbles and design flows. It makes it very organic and approachable.

Full disclosure: Romain Guy is one of my mentors for the Google Summer of Code and I am also conversant in French. Neither of which should be held against me. The book is available on pre-order from Amazon.com and in electronic format from Safari Rough Cuts. Lol.

I like the concept but am not exactly enamored with the execution. I've been watching the project for a while but I feel the approach is wrong. If you look to any other platform, most notably .NET, there are a small number of ways to do things, many times even just one. It's often been said that Java dies from the ability to choose, splitting market share so much that developer confusion ensues. I'm not suggesting that there be only one option. If a new one is introduced, it should bring significant value. No disrepect to Chris Oliver but I don't believe it does. As noted elsewhere, the syntax is a bit reminiscent of the SwingBuilder. No worries about that, it's not like Groovy has a patent on syntax. :-) My main gripe is that it seemed like the FAQ bashed Groovy for no reason.

"Groovy and other languages have two specific traits which don't precisely meet these needs, namely that they are generic in nature and don't provide the appropriate abstractions necessary to optimize the UI design process and similarly are designed specifically for programmers other than content authors."

Builders can make Swing incredibly simple. One could argue that Groovy builders trump F3 cum JavaFX because they are ingrained into the language and not a DSL on top of Java.

We have had to explain for years that ECMAScript(J*vascript) and Java have nothing to do with each other and was just a marketing ploy. "You're good in Java, right? Do this JavaScript thing for me." F3 was cool, descriptive, very mathematic. JavaFX is blah. For the record, I prefer AB5k over Glossitope as well.

Since I'm coming close to a decently working version with barebones functionality, and a decent amount of chatter on the mailing lists, I've talked it over with MrG(Guillaume) and I will be implementing some of the F3 demos with the Swing(X)Builder. ETA is currently unknown, I wanted to wait a little bit to really familarize myself with it and not be one of the also-blogged* in the aftermath of JavaOne. Expect it in probably a couple weeks.

[Yeah, it's a made-up phrase, or so says Google. In this context, I mean blogging on something after the fact being nothing more than a regurgitation of established facts and/or stints of blatant anti/fanboy-ism without any offering of either new or supporting data.]

My initial though is a resounding no. Before you start typing a comment, hear me out. With most components, layouts, widgets, you can very quickly figure out in your head how they will be implemented. Not so with GroupLayout. GroupLayout is already a mish-mosh of enchained groups. Converting it to Groovy’s builder paradigm would make it look more spaghetti code-esque. Why should it be supported in the first place? IMHO, I think that whatever GroupLayout can do, GridBag can do as well. MIGLayout, of recent press on JavaLobby, looks like it could fill this role as well.

Note: My GSoC project is to create a SwingXBuilder.