It started out innocently enough, with Andres Almiray coming to me at JavaOne 2008 and suggesting the next great idea for the SwingBuilder: make the bind node work with closures. Well, at least well behaved closures. Because sometimes terseness adds more to readability and usability than rigor does. Consider these two lines, which would you prefer to code and read?

label(text: bind(source:model, sourceProperty:'value'))
label(text: bind {model.value})

Certainly, it should be the second line. Immediately my head started to churn, and my first impression was 'is there some way we can make AST Transformations do this?' Because (a) the first beta of 1.6 had just gone out with AST Transformations making it's debut and (b) this seemed like a compile time problem. But quickly things came screeching to a halt. You see the problem is that in Groovy all method calls and property references are dynamic. Meaning that they go through the Meta-Object Protocol (MOP) to dispatch the call or resolve the value of the property. And the actual methods used to resolve these values can be completely altered at runtime (with the right permissions). This presents a problem with compile time transformations: how do you safely do a transformation on a symbol that may not mean what you think it means at compile time? The short answer is you don't. (The longer answer is deserving of another blog post).

So how can I bind to a somewhat arbitrary closure, one who's meaning isn't fully resolved until runtime? The answer is to use the same mechanisms the closure uses at runtime to resolve it's values, but make a mockery of it instead. Err.. I mean.. use the mock object pattern. This is actually where I started to learn more about the incantations of closures than I intended.

In Groovy, each closure creates a separate type, whose name is a mechanical mangling of the owning type: <Class Name>$_run(_closure<number>)+ and each of these types extends groovy.lang.Closure. However, a closure needs to get some access to the methods and properties of the scope in which it was declared and/or in which it is executed. To this end, it has an owner field, which is always set to the instance it was created in, and a delegate field which can be set to any old object. The resolveStrategy property on the closure is then used to determine which of the fields to use and the order to address them in to resolve methods and properties not directly know to the closure. This was simple enough, since I already exploit that knowledge to get any of the builders to work their magic in the first place. However, once I got the simple case working, the real magic of closures made itself manifest: lexically scoped variables. Consider this script:

String bar = "long"
def closure = { [bar.length(), baz.length()] }
bar = "longer than long"
closure.delegate = [bar:"short", baz:"short"]
println closure()

What will the result be? Wait for it.... is it [4, 5], [5, 5], or [16, 5]? The correct answer is, of course the last one. But how can that be? In Java with an inner class I would be forced to declare bar final, and remove the third line since I cannot alter it, so in Java the first answer would almost always be true. But to get the second answer instead of the third one I would have to remove the typedeclaration for bar, and this is the point where I started to see some of the deep magic at work. Whether or not bar is defined as a free variable or a lexically scoped variable is an essential distinction for a Closure. Properties are not lexically scoped variables, and lexically scoped variables are not pushed through the MOP for resolution like properties are. Lexically scoped variables basically have a static meaning, even when used in a closure that may leave scope. (note: the variables themeselves are not subject to the MOP, but the methods or properties on said variable, those are subject to being MOPed up).

So when Groovy compiles a closure and generates bytecodecode it looks over the lexically scoped variables it can see, and compares it against the symbols that the closure is using. When it encounters a variable that is used by the closure it does two things, first it adds to the closure an argument in the constructor, a field, and a getter method to access the variable within the class. Java does this for Inner classes so it is not too shocking. But the second thing it does, which is simple but powerful, is it wraps all access to the variable in the enclosing scope and in the closure inside of a groovy.lang.Reference object. The code looks like it may be accessing an Object on the stack, but the compiler alters those calls for you so you are actually accessing the reference object and using get and set to read and write to the variable. This allows the variable to, in essence, outlive the stack frame it was created in and for other closures to act on the variable in a manner that can be shared across other closures. Consider this slight alteration...

String bar = "long"
def closure = { [bar.length(), baz.length()] }
bar = "longer than long"
def change = {bar = "Doh" }
change()
closure.delegate = [bar:"short", baz:"short"]
println closure() // [3,4]

Providing an alternate value in the delegate still has no effect, but altering it's value inside another closure does affect it. Knowing this I could now create a separate instance of the Closure and fully mock it up against both lexically scoped variables and free variables in an equivalent fashion. The simple act of adding a type to a previously unbound variable will now no longer break things in strange and mysterious ways. Making things work like magic made me learn more than I ever expected to know about how Groovy implements Closures.

Model View Controller Separation

The GUI has a firm model view controller separation. All of the Twitter API functionality is sequestered into the TwitterAPI.groovy class. No other class does network functionality. The GUI code is also handled separate from the controller. View.groovy is the main class, whereas a couple other classes (ScrollablePanel.groovy, RoundedPanel.groovy) are there to support the view portion. One other view class, TweetLine.groovy, handles the rendering of the individual tweet line (because I was not satisfied with JList). Finally there is the controller class, Greet.groovy. In addition to the main method all Swing events are dispatched to the various controller methods. State variables are also kept here.

Use of @Bindable and bind()

A lot of the glue code to manage visual state with the controller has been automated because of the new @Bindable annotation in Groovy 1.6. This allows me to send notices that the view shouldn't be accepting updates and also notify the view that the backing data model has changed. Adding these hooks by hand would add at least 100-200 lines to the application and would also introduce repetitive code that is prone to cut and paste errors. The view code uses the bind() node to easily bind the values of the actions to relevant attributes.

Actions are your friends

Less of a Groovy call out and more of a Swing call out. Use actions, actions are your friends. All of the buttons, text lines, and list boxes are not hooked directly to the controller, but to the action. This causes all of the relevant controls to turn off when the action becomes unavailable, and is why the bind to enable occurs in the actions definition and not the control definitions.

Builder scripts are still Groovy Code

In line 142 to 147 of View.groovy I do a loop inside of a panel to add the tweet lines individually, calling out to the TweetLine.groovy script. This is perfectly legal in Groovy, since a builder is actually just executing closures and using meta-programming to intercept the method calls. It may look like a static declarative XML type file in most cases, but it doesn't have to. Especially with repeating elements, it's a great way to DRY out code.

The 'Dynamic Language' part is what makes it possible

The dynamic language aspect of Groovy code (and in particular the Scripts) is what allows for most of the magic to happen. It is essential to the builder pattern. You will also notice that both of the principal view scripts (View and TweetLine) don't create a SwingBuilder, or even imply that one exists. They also use variables that are not defined in the scope of their script (like the controller object and the tweet). This provides for a very subtle form of resource injection that requires no ceremony to access. If this were statically typed I would have to state somehow the methods and fields the controller and tweet have, even if by simple type decleration. All of that formality is unneeded in this context.

So what is the future of Greet? I intend it to be one of a few marquee examples for a project I am attempting to get off of the ground with a few others, so the WebStart version may see some changes every once in a while. But that is also why I am a fan of the promise of WebStart (if not particular shipped versions), new versions can be distributed without the same ceremony as an installer.

Consider these external numbers from The Computer Language Benchmarks Game. Left is the comparison implementation, right is Groovy. White is speed, black is memory consumption. Measures are relative to each other.

First, JRuby 1.1. (Note: JRuby 1.1.1, wasn't on the alioth site)

This surprised me. Charles Oliver Nutter has been working intently on making the JRuby call sites work very well with the HotSpot optimizations. Lots of talk about monomorphic branch paths, reflection barriers, and other stuff that makes my head hurt like I'm back in my undergraduate algorithms class. Groovy beat JRuby in most of the tests (it used to be all but one, but it looks like possibly it got the JRuby 1.1.1 update). I'm not sure why however. Possibly better loop optimizations.

I remember that Charles was excited that some JRuby benchmarks had been running faster than Ruby, and that it was running Rails faster, some I compared Groovy against Ruby 1.8.6.

The first two places Ruby beast groovy are not surprising, calculating the digits of Pi and regular expression searching of DNA sequences. The last on we get spanked on, printing hello world. This is partly because the way the test is set up groovy both compiles and executes the test, then there is plain old jvm startup time, even plain old Java loses to Ruby in that one. There is also the issue of memory consumption. Generally speaking Ruby has a better story when it comes to these benchmarks.

Ruby gains some ground when using the YARV vm in Ruby 1.9, but Groovy still maintains a performance edge, while getting beat on memory for the most part.

Now I am not claiming that Groovy is the most performant language on the JVM, it isn't. But it's performance story has improved markedly. Since groovyc can jointly compile plain old java (which is slightly faster than Scala) it provides a nice fallback for performance intensive parts that are critical.

Now it's time to pack for JavaOne.

Update: Some of the analysis is off because some of the groovy programs that are missing are being filled in as time goes on. Some of these are as partial sums and reverse complement (which Groovy stinks at apparently) and more (like k-nucleotide) are to come. I am also directly linking to their images, so as the other implemetnations get updated, the images will change.

So I am going to this Baseball Salary Comparison (via NYT/Freakonomics) in Mozilla and I am scratching my head. Is AJAX that powerful now? Did flash sneak into my plugins? Is Silverlight in XP SP3? So I view the source and... oh my... it's referencing a class file. Where was the browser halting startup? The grey box? The orange java logo? I look down to my system tray and, yep, there's the java logo. I do have 6u10Beta installed, so all of the consumer oriented goodness is wired in by default, and it worked.

Oh my, I started a Java applet and didn't know it.

About time.

@groovy.beans.Bindable is an annotation that can go either on a Groovy class property or a Groovy class itself. When the annotation is on a class you are telling the transform that all properties declared in the class should be treated as having @Bindable (whether or not they already have it). When a property has this annotation the AST Transformation will generate (if it doesn't exist) a java.beans.PropertyChangeSupport object, appropriate listener addition methods, and then a setter that uses the property change support. The end result is a bound JavaBeans property, with a whole lot less boilerplate code. What was once this:

import java.beans.PropertyChangeSupport;
import java.beans.PropertyChangeListener;

class MyBean {
  private String prop;

  PropertyChangeSupport pcs = new PropertyChangeSupport(this);

  public void addPropertyChangeListener(PropertyChangeListener l) {
    pcs.add(l);
  }

  public void removePropertyChangeListener(PropertyChangeListener l) {
    pcs.remove(l);
  }

  public String getProp() {
    return prop;
  }

  public void setProp(String prop) {
    pcs.firePropertyChanged("prop", this.prop, this.prop=prop);
  }
}

now looks a lot more concise and to the point:

import groovy.beans.Bindable

class MyBean {
  @Bindable String prop
}

This goes hand in hand with the bind() node in swingbuilder, making a model update a text field automatically when it changes is now a simple as textField(text:bind(source:myBeanInstance, sourceProperty:'prop')). This is a very sublte thing to grok, but it really goes a long way in cutting down the amount of lines it takes to link the model and the view togeather in a client application.

The same premise goes for @Vetoable, you know, for all those constrained JavaBeans properties you write. You know, just in case. I have seen some code in the wild that uses VetoableChangeListeners, but not indexed JavaBean properties. It is useful for validation, when architected properly.

//Panel.groovy
panel(id:'loginPanel') {
  tableLayout {
    tr {
      td { label(text:'Username') }
      td { textField(id:'usernameTextField', columns: 20) } 
    }
    tr {
      td { label(text:'Password') }
      td { passwordField(id: 'passwordTextField', columns: 20) }
    }
    tr {
      td { panel() }
      td { 
        button(text:'Login', actionPerformed: { 
          println user.username 
          println user.password 
        }) 
      }
    } 
  } 
}

bind(source:usernameTextField, sourceProperty:'text', 
     target:user, targetProperty:'username') 
bind(source:passwordTextField, sourceProperty:'text', 
     target:user, targetProperty:'password') 

With this model in a separate file (because I'm that kind of coder on occasion)

//User.groovy
class User { 
  String username 
  String password 
} 

Now before we go any further we will compile these scripts. Yes, with groovyc. If you are wondering if these are the complete sources the answer is yes they are. You are also correct in noticing that there is no import or use of SwingBuidler. <soapbox>This, my friends, is the power of a dynamic language. The MOP dispatches these calls, and when the script is actually invoked is when these symbols are resolved. When the SwingBuilder consumes the script it links itself into the script's metaclass to intercept all unresolved calls.</soapbox> Sorry, evangelical tangent there for a moment. Let's get back on task. How does the Java code look?

//JavaSwingBuilderDemo.java
import javax.swing.JPanel;
import javax.swing.JDialog;
import groovy.swing.SwingBuilder;

public class JavaSwingBuilderDemo {

  public static void main(String[] args) {
    SwingBuilder swing = new SwingBuilder();
    
    // load all externally referenced variables
    User user = new User();
    swing.setVariable("user", user);
    
    swing.build(new Panel());
    
    // unload the desired components
    JPanel result = (JPanel)swing.getVariable("loginPanel");

    JDialog dialog = new JDialog();
    dialog.getContentPane().add(result);
    dialog.pack();
    dialog.show();
  }

}

To invoke the script you do it much as you would in groovy, just with a lot more typeing. Both the keyboarding a casting kind. The main call is SwingBuilder.build(Script). This calls the script as though it was being evaluated in one of the builder's content nodes. Of course, before you call the script you need to load in any external variables, in this case a user object that contains the username and password. Then after the call you need to unload the variables you want to use. In Groovy I could just do swing.loginPanel but in Java no implicit meanings are allowed, so that means more typing.

An interesting side note is that this is similar to something we are looking at doing inside my own company: using SwingBuilder to build and wire up the GUI while keeping the core of the application in Java and keeping those who don't have the time to learn Groovy or want to deal with it from having to do so. And that is what I find great about Groovy: you can use it where it makes sense and adds value, and where you transition it's relatively seamless (unless of course you are using Seam ;) )

My submission for a Technical Session at JavaOne has been upgraded from an alternate to an accepted session! TS-5098 - Building Rich Applications with Groovy's SwingBuilder. This will be given with Andres Alamiray. This is basically an intro to using Groovy to build Swing applications. No word on when the session will be however.

This is in addition to my BOF session on Wednsday Night with James Williams: BOF-5110 - Extending Groovy’s Swing User Interface in Builder to Build Richer Applications, which will go over how to add your custom widgets or leverage commercial libraries in the SwingBuilder.

In addition to the basic language level changes, there are a lot of changes that went into Groovy's Swing support.

Backend overhaul

• Almost every line in the SwingBuilder was adjusted in some way. And the whole thing was ported over to Groovy from Java. Dogfood baby!
• FactoryBuilderSupport is a juiced up refactoring of SwingBuilders building pattern. SwingBuidler is now a subclass of FactoryBuidlerSupport fully using Factories for all of it's classes, and node specific handling has similarly been moved to the factories out of the SwingBuidler core.
• At the FactoryBuilderSupport level a new build() method was added, so external Groovy Scripts can be called and executed as though they are builder content directly.
• Also at the FBS level nodes that create object that should be disposed are tracked via addDisposalClosure(), which are all called in FILO order from the dispose() method.
• Most nodes now accept an object of their own type, providing another point of extension. i.e. button(new MyCustomButton()) works as expected if MyCustomButton extends JButton

New Nodes

• actions(), a simple collection node that is meant to describe actions
• imageIcon() provides support for ImageIcons
• Borders are now supported via buidler nodes. lineBorder(), loweredBevelBorder(), raisedBevelBorder(), etchedBorder(), loweredEtchedBorder(), raisedEtchedBorder(), titledBorder(), emptyBorder(), compoundBorder(), and matteBorder().
• bind() and model(), adding binding support for observable properties.
• The passthrough widget() now has two use specific cousins, container() for widgets that can have children (widget() now throws an error when children are added) and bean(), which will not add the resulting object to the parent container. (Note that the expanded argument support for the basic nodes should reduce the necessity of these nodes. Just add the new widget as an argument to it's javax.swing type.)

New Methods

• edt(Closure), executes the Closure in the Event dispatch Thread (EDT) and wait for completion (via SwingUtilities.invokeAndWait). Optimizations are performed for when the method is called in the EDT.
• doLater(Closure), executes the Closure in the EDT asynchronously via SwingUtilities.invokeLater()
• doOutside(Closere), insures that the closure is executed outside of the EDT. If the context is not in the EDT it is executed immediately, otherwise a new thread is created
• shortcut(key [, modifiers]), given a keystroke it adds a platform specific modifier for it (ctrl on Windows and GTK, option on MacOS).
• dispose() invokes all disposal closures. Generally these are things such as dialogs, frames, and windows created by the SwingBuilder and unbinds all bindings created by bind().
• lookAndFeel() is an easy way to set the look and feel. Defaults exist for system, metal, nimbus, etc. and a few third party LAFs.

New static method

• build(Closure), creates and returns a SwingBuilder and executes the closure in context of the Event Dispatch Thread.

java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.waitRunning(JPDADebuggerImpl.java:290)
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.finish(JPDADebuggerImpl.java:1039)
org.netbeans.modules.debugger.jpda.actions.KillActionProvider.doAction(KillActionProvider.java:74)
org.netbeans.api.debugger.ActionsManager.doAction(ActionsManager.java:158)
org.netbeans.api.debugger.Session.kill(Session.java:278)
org.netbeans.modules.debugger.ui.models.SessionsActionsProvider$3.perform(SessionsActionsProvider.java:97)
org.netbeans.spi.viewmodel.Models$ActionSupport.actionPerformed(Models.java:528)
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
javax.swing.AbstractButton.doClick(AbstractButton.java:357)
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
java.awt.Component.processMouseEvent(Component.java:6038)
javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
java.awt.Component.processEvent(Component.java:5803)
java.awt.Container.processEvent(Container.java:2058)
java.awt.Component.dispatchEventImpl(Component.java:4410)
java.awt.Container.dispatchEventImpl(Container.java:2116)
java.awt.Component.dispatchEvent(Component.java:4240)
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
java.awt.Container.dispatchEventImpl(Container.java:2102)
java.awt.Window.dispatchEventImpl(Window.java:2429)
java.awt.Component.dispatchEvent(Component.java:4240)
java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Yes, Netbeans totally froze up on me, because some overworked programmer thought it would be good to do a blocking wait without timeout in the Swing Event Dispatch Thread. If a single problem happens you are stuck in limbo forever. Which is why non-timeout wait calls can be so evil, and doing it in the EDT makes it demonic. Looks like we need to get the stick back out, or punish whoever it is that violated their blood oath.

Really, I'm not just being petty. I've sent may stack traces like this to the bugzilla at NetBeans for years, literally years, and they still are doing messed up things in their action handlers without checking to see if they are in the EDT. It may have the best GUI designer for Java out there, but the frosting doesn't matter if you cannot stomach the cake.