Danno Ferrin: Groovy on the desktop does matter
Danno Ferrin is a member of the Groovy Swing team. His contributions have made programming Swing with Groovy a better experience. Learn about his work on SwingBuilder and Grape. Enjoy! [note: typos are Danno's signature, not errors :-)]
Q. Danno, what can you tell us about your contributions to Groovy ?
A. Most of my contributions have been in the SwingBuilder, and some other random bug fixes here and there. My main contributions tend to be things that will add value to the desktop story of Groovy, such as my multiple attempts to get @Bound and @Constrained annotations working for the automatic Groovy JavaBeans properties.
Q. Automatic Groovy JavaBeans? tell us more!
A. The JavaBeans spec has support for more neat tricks than just the event pattern and the getter/setter pattern, there is support for design time information and user-defined meta data. The issue is that most of this involves creating a parallel class telling the Introspector what is going on. When the Introspector cannot find a BeanInfo class it resorts to looking for a standard set of patterns, a classic example of convention over configuration.
The problem is that not all of these conventions are easy (constrained properties for instance) and the build in support classes still require a lot of repetitive code to implement. Groovy started down the path of making this easier in the early days by making any class field that doesn't have a scope modifier (public, protected, private) a property, and generating the getters and setters for you, eliminating a lot of cut and paste code in the process. @Bound and @Constrained (currently looking to be released in Groovy 1.6) automate more of the process. More improvements are possible, such as automatic generation of BeanInfo classes, and auto generation of the listener pattern. But we quickly run into the law of decreasing returns since these features are not used nearly as much as get/set.
Q. What other contributions have you made to enhance the desktop experience ?
A. Some of them seem like generic bug fixes, but were done with the desktop in mind. For example, the map expression ([name:'value']) used to use a HashMap, and it was changed to use a LinkedHashMap so that the order of the map elements is preserved. It had an impact in the order of setting properties on a particular widget. Code to Sanitizing the stack trace was ported over from Grails to make the console stack traces more relevant. There are other more basic features such as groovy.binding and the bind node in SwingBuilder to automate data binding that are more portable and generic rather than code directly affecting the swing layer.
Q. I've seen some posts on the mailing lists about Grape, what is it ?
A. Grape stands for the Groovy Adaptable Packaging Engine. It originated in a debate we had on the developers list relating to Jar file bloat that was beginning to happen on the road to the 1.5 release. Some were advocating for a streamlined distribution and wanted a streamlined means to make newer features available in the core (like TimingFramework animation) without burdening people who have no interest in the desktop world (scripters and web developers). The solution that was agreed on is some sort of a module system like Python's Eggs, Ruby's Gems, or Debian's apt-get.
The core issue is that modularity means different things to different people. OSGi handles one aspect of modularity I would call "partitioning," where the modularity system manages the VM classloaders to provide requested services from one module to the other (including possibly different versions of the same module simultaneously). Grapes may address the partitioning problem one day, but the Proof of Concept written today doesn't address partitioning.
The Proof of Concept for Grape I wrote addresses what I would call "provisioning," i.e. how the user gets the module into the system. The way I see it solutions to the provisioning problem can be split into two taxonomies, the make the user do it pattern and the do it for the user pattern. The Proof of Concept is the latter, and it leverages the latest beta code form the Apache Ivy project and Maven and Ivy repositories to do the provisioning. I really wasn't interested re-inventing solutions that Ivy has dealt with in the caching real and Maven repositories are the 800 pound gorilla (or Grape Ape) in the Java dependencies game.
What I am hoping this will enable is for desktop developers to be able to use more non-core widgets in their applications, such as the JIDEBuilder, and not have to play hide and go seek with Jar files.
Q. Do you foresee an integration of Gant and Grape in the future because of these challenges ?
A. I'de say Gant and Grape are addressing problems in entirely different scopes. Grape is meant to be a more general purpose declarative tasking engine (usually as a build engine) whereas Grape is addressing runtime provisioning of libraries. The use of online repositories is optional for Gant but is core to Grape. When Gant uses maven tasks or Ivy tasks the files are also by default cached in different locations. However there is some crossover. Because Gant scripts are also Groovy scripts a Gant script could use Grape to automatically grab a set of ant tasks that are used by the script.
Q. How did you get involved with Groovy ?
A. Initially Groovy caught my eye in 2004. Mainly it was the SwingBuilder then and it's declarative UI for Swing (the SwingBuilder). But what I most liked was the incredibly terse code needed to add a button listener. Groovy's closures were much easier on the eye than lots and lots of anonymous classes. In 2004 I had submitted a few patches James Strachan applied. However I took a few years off due to my first child and going back to college to finish off my degree (with only one semester left I really didn't have an excuse). I picked it back up in 2007 after the 1.0 release submitting some patches for SwingBuilder again. Guillaume took notice and granted me commttier access, and I proceeded to refactor most of the SwingBuilder as well as introducing other fixes that would enhance desktop Groovy.
Q. Do you use Groovy at work ?
A. Not yet. I work for a defense contractor who made an early investment in desktop Java (circa 1998). Our largest codebase (that almost all of our projects build off of) consists of a lot of hand coded swing and database code, and back in the last millenium there wern't that many other options than hand coding. Introducing Groovy is going to have to be a calculated decision. Anyone who as worked with software that has that long of a history knows that managing the stability is a major process, so just upgrading the version of an jar in the core product requires the blessing of the Change Control Board. Because, lets face it, applications don't get to be 10 years old with anarchistic configuration management policies.
However, there is a growing grassroots support for Groovy for the features it adds. Things such as DSLs, Grails, and scripting would solve a lot of the pain we are feeling in some of our engagements. What makes it even a consideration is that (a) it integrates strongly and seamlessly with out existing Java codebase, and (b) all it requires at runtime is adding another Jar to our JAR libraries. We also have a lot of IntelliJ fans here, so IDE integration is an instant win as well. So I expect to see it in production code here before too long.
Thanks for the interview Danno!
Danno Ferrin has been developing with Java professionally since version 1.0 in 1996. He worked with emerging technology as they have grown from early trend setters, such as NetDynamics to established technologies. He was an early committer to the Apache Tomcat and Apache Ant projects, and participated in JSR expert groups for Servlets and JSPs. Professionally he is employed by Intelligent Software Solutions, a fast growing developer of data integration and visualization for government applications. In the Open Source world he is an active commiter for Groovy, focusing on the desktop and Swing related aspects of the language.