I've interviewed our own Andres Almiray, author of the amazing Groovy GraphicsBuilder. Learn his thoughts on Swing, Groovy and simplifying Java2D.
Q: Hey Andres, you're the author of the GraphicsBuilder. Can you tell us what its for?
A: Well in short words, GraphicsBuilder is a groovy builder for Java2D. Like SwingBuilder for Swing, GraphicsBuilder will let you create Java2D drawings in an easy and intuitive manner. In SwingBuilder nodes are mapped to swing components, in GraphicsBuilder nodes are mapped to objects of type GraphicsOperation, those are the objects that know how to render graphics artifacts, making a comparison to Sun's scenegraph project, graphics operations relate directly to SGNodes. But the fun doesn't stop there, because GraphicsBuilder accepts any groovy code inside its building closures, enabling repeated drawings with loops and iterators and so forth, exactly in the same way other groovy builders work.
Q: Ok, so what is a builder then?
A: A builder is a class useful for creating hierarchical data structures, it usually provides an abstraction over the data or domain you are working on, relieving you of tangle code. Let's take for example SwingBuilder and Swing. All swing applications are hierarchical structures of components, with a window or frame usually as the root component, after them comes the root panel, content panes, layouts, buttons, labels and so forth. One of the reasons we have visual designers is to hide the complexities of putting all those components together in a way that pleases the eye and become usable. In many cases the resulting code may be completely unreadable by humans, modifiable only by the design tool itself. SwingBuilder gives back control to the developer, as the code used to create the UI expresses the hierarchy in a very readable format and also allows you to mix any valid Groovy code into it. I must say I'm not against design tools, in fact I'd love to see one that exports to groovy code understandable by SwingBuilder, but I have found myself more often than not doing quick UI prototyping with Groovy's console instead of using a design tool. Other great examples of builders in action are MarkupBuilder and ObjectGraphBuilder. MarkupBuilder lets you create HTML/XML, ObjectGraphBuilder lets you create a graph of JavaBeans, useful for creating testing data.
Q: How and when did you get involved in Groovy?
Q: On your blog there are some impressive screenshots, especially compared to the amount of code it takes. What can you tell us about creating your own DSL in Groovy?
A: The task may be seem a little bit daunting at first, as there are many options for creating DSLs in Groovy. Should you use categories? or is a builder a better choice? what about other meta programming options like ExpandoMetaClass? In the case for GraphicsBuilder it was clear from the beginning that it should be a builder as the shapes may be grouped in hierarchies, as swing does for components. The builder option is also the most straight forward, thanks to the useful features provided by FactoryBuilderSupport, the next generation of builder base class, its as easy as registering a factory for each node, the builder will take care of the life cycle.
Q: The examples combining GraphicsBuilder and Swing are equally impressive. What kind of applications can you see GraphicsBuilder being used for?
A: That is a good question. GraphicsBuilder creates drawings but it also provides binding and animations, so its very likely to make it into the RIA space, for example as provider of dynamic overlays on maps. In the following versions it will include the ability to apply filters and effects to drawings and images, laying the ground for quick photoshop-like image editors. GraphicsBuilder can also work on the server side, producing images on the fly, I think a Grails plugin is not that far away.
Q: Animations? Tell us more!
A: Animation support is still in the early stages, right now it uses TimingFramework under the covers, there some rough edges here and there. Still you can animate almost anything created by GraphicsBuilder, and for those occasions where the animate() node will not give you what you want, you can use bind() on a property and go old school animation with custom threads. Here I'd like to point out that Groovy provides an ObservableMap class, simplifying the creation of observable beans as event sources, it can even be used in conjunction with Expando, giving you dynamic, observable beans on the fly; great for quick prototyping.
Q: Do you have a background in Swing?
A: Yes, I've been involved with Swing applications for several years but at some point succumbed to the web application gravitational pull, to later return in force back to Swing development. At one point I participated in a project making a Kiosk application based in Swing which worked really well and has been successfully deployed. It was precisely during that project when I discovered Groovy.
Q: What is your most important source of information when you're developing in Groovy?
A: As the saying goes "Use the source Luke". I like to read source code a lot, be it snippets or full project sources. I also dig for gold nuggets on blogs and articles, but when there is nothing around I fire up Groovy's console and play with the API at hand, see what makes it tick. The lack of documentation support in tools like IDEs doesn't hurt me that much (it surely is welcome), but I'm hopeful that will change in the months to come.
Q: Do you use an IDE when developing in Groovy? If so, which one? If not, don't you need one?
A: I used to believe IDEs were evil, then some years ago I gave Eclipse a try and got hooked. I still use it for Groovy development, as sometimes you need to write Java code that goes along (I love that level of integration between the two languages). A trusty companion is again Groovy's console, I often find myself coding in Eclipse, switching to the console to test a theory and getting back to the editor. Being able to test the code as you write it without being delayed at all times by the usual code-compile-run cycle is great for me.
Q: Come to think about it, couldn't Swing use a builder like GraphicsBuilder, one that goes beyond what SwingBuilder does and creates impressive GUIs with minimal code? I'm thinking about an integration of some of the Swing tricks and hacks by Romain Guy and others.
A: Wouldn't that be amazing? I'm happy to say that the Groovy Swing team started to take measures to achieve that goal, something like an "UberSwingBuilder" that groups together SwingBuilder (and it's offspring SwingXBuilder & JideBuilder) with GraphicsBuilder and some others. Ideas are still being thrown around, I'd love to have something demonstrable by mid-year, we will see if that is possible.
Thanks for the interview Andres!