Griffon is a framework for building rich desktop applications. It leverages the Groovy programming language and a number of the key features of Groovy including builders. It’s a fantastic effort and while it’s still fairly early days, the team is making great headway with the roadmap. The first episode of the GriffonCast is available for viewing and/or downloading. If you have any comments or would like to see specific topics covered drop me a note or post your thoughts on the Griffon mailing list.

In this session, Amy Fowler, Jasper Potts, Paru Somasheka and David Grieve all from Sun took the Swing application that was written for last year’s installment of the GUI Makeover and added a bit of Java/FX. The idea is that there is a bit of a migration path for existing swing applications to Java/FX.

javafx.ext.swing.SwingComponent is the Java/FX component that can be used to wrap any existing swing component. The resultant object is a Node object that can be added to the FX scene graph. This is a decent approach but the biggest drawback is that none of the core elements for Java/FX (like transitions) can be applied to the contents of these kinds of nodes. They showed the CSS skinning approach that can be taken with Java/FX applications. It’s a good idea to separate the style (colour, font, size etc) from the actual components. Lastly Jasper showed an illustration of a an annimation on the Scene Graph.

It was pretty impressive all in all.

Move Your Users: Animation Principles for Great User Experiences

This session was presented by Chet Haas and Romain Guy. They introduced 12 animation principals that are documented in the book. The principals are related to traditional animation (cartoons) but they are very applicable to computer animation as well. They followed up a description of each of the principals with it’s application in building rich user interfaces on desktop applications. They did a great job. The content is something folks should consider when they’re implementing any sort of animation in their applications even things as simple as a fade transition or a scale. It’s really easy to get this stuff wrong and learning from the masters of animation who have been thinking about this stuff for almost a century could make a huge difference in your application.

The 12 principals are:

• Squash and Stretch
• Anticipation
• Staging (poses, camera angle, focus)
• Straight ahead vs. pose to pose (related to transitions)
• Follow through and overlapping action (objects should obey physical reality)
• Slow in and out (non linear timing)
• Arcs (things generally don’t move in a perfectly straight line)
• Secondary Action (an additional action that gives context to the main action)
• Timing
• Exaggeration
• Solid Drawing
• Appeal

One of the sources for their presentation was The Illusion of Life: Disney Animation

The Magic of the JXLayer Component

This session introduced the JXLayer component which is currently a java.net project. JXLayer is a wrapper or more precisely implements the decorator pattern for Swing Components. It has a bunch of different uses including a very lightweight way of disabling compound components, implementing mouse wheel scrolling as well a many other uses. We use this component in our framework quite a bit mostly in and around our UI security implementation. It’s great and if you write any Swing code and don’t know about this component go have a look. It was also announced in this session that this component is being promoted into JDK 7.

JavaFX™ Programming Language + Groovy = Beauty + Productivity

Dierk König author of Groovy in Action (still the best book on Groovy written to date in my opinion), presented a couple of different approaches to integrate groovy with Java/FX. One strategy is to use Java/FX for client code and then use a REST layer to have the Java/FX client talk to a back end written in Groovy (or Grails for that matter). This approach is pretty clean but you don’t get to take advantage of any Groovy code on the client.

Both Java/FX and Groovy are JVM languages and ultimately emit bytecode from their respective compilers. It is possible to reference Java/FX components from within Groovy but it’s messy. Andres Almiray has a JavaFX builder in the Griffon Project that begins to make this integration easier but it’s still early days.

The short answer is that true integration at this point in time is hard and will get better as Java/FX matures.

Hudson Community Meet-Up

I’ve been looking into Hudson for a few months now and it just keeps getting better and better. The project lead (Kohsuke Kawaguchi) gave a bit of background and some of the current trends of Hudson. The growth of the product and the community surrounding it since last Java One is very impressive. Plugins for Hudson are one of the distinguishing features. Tom Huybrechts from AGFA Healthcare demoed a new plugin he wrote that implements the JBoss Rules Engine (drools) within Hudson. Layered on top of it is a graphical builder for building workflow steps, gathering input at various points in the workflow and a ton of other cool stuff. It was very impressive and something I want to take a closer look at.

Netbeans project integration was also demoed (actually talked about as there was a technical glitch with the netbeans machine/projector combo). It would be interesting to monitor builds from within Netbeans, kick them off etc. but given that we’re an IntelliJ shop it’s not that relevant. There may be some form of plugin for IntelliJ but the web interface is great so I’m not sure we would even look at it.

Griffon in Depth

Danno Ferrin and James Williams gave an introduction to Griffon which is a Grails inspired framework for building Swing applications in Groovy. It’s still very early days with the project however the project team has leveraged all of the great work from the Grails project in bootstrapping the Griffon project. This is one technology that I’m quite excited about. Writing swing apps in Groovy is possible (see this post for an example) however writing a big Swing app would be quite a lot of work. The idea behind Griffon is to put a framework in place to support building Swing applications with the same sort of velocity the web guys are seeing with frameworks like Grails and Ruby on Rails. The fellows demoed a few applications written in Griffon the most impressive one was Greet which is a Twitter client written in Griffon. I wish the fellows much luck with this project and I’m trying to figure out a way I can help in some small way. Swing and Groovy in the same stack makes me very happy

Java FX

I’m sure this year will be all about the Desktop (again) with Java FX. I’m mildly interested to see what all the hype is about. I’ve been a Swing guy for most of my Java life and while I am excited about seeing some of the new shiny tools and techniques (Scene Graph being very high up there), part of me is sad to see so much engineering time and resources being focused on this. Amy Fowler is doing a session entitled Extreme GUI Makeover (Hybrid Swing and JavaFX™ Technology) which promises to be a Pimp my Swing App with Java/FX.

Groovy

I first learned about Groovy at Java One in 2004 where James Strachan gave an introduction and overview of the language. This was the first time I had considered using anything else except for Java on the JVM and I remember having one of those ‘light bulb’ moments in the session. It’s totally changed the way I think about the JVM and languages in general. We’re a pretty heavy user of groovy in our application and I’m quite excited to see a number of Groovy sessions at Java One this year.

Some of the sessions that have caught my eye are:
What’s New in Groovy 1.6? with Guillaume Laforge
Griffon in Depth with Danno Ferrin and James Williams
“Design Patterns” for Dynamic Languages on the JVM™ Machine with Neal Ford
The Groovy and Grails BOF: With Live Grails Podcast Recording! with Sven Haiges and Glen Smith of The Grails Podcast

Java EE

Not nearly as sexy as Java/FX, the Java EE space will probably see some new announcements and updates on some of the key JSRs. I haven’t really been following the progress of the JCP that closely and can usually get all I need to satisfy my curiosity at Java One.

Summary

I’m really looking forward to it. San Francisco is one of my favorite cities and having been there a few times I’m starting to have a few favorite haunts including a new one I found last year. If you’re going to Java One this year, drop me a note on Twitter.

If you would rather not hear me blather on describing this code, you can see a quick 20 second demo of the running application here.

I decided to write a little groovy app that displayed a few participants from the roundup and their origin airports on a Google map. I wanted to illustrate a few common Groovy idioms and illustrate how easy it is to create a pretty functional app in just a few lines of code.

The first thing of note in the script is a small class that represents an Attendee. Notice there is no constructor, no getters or setters. The only method in the class is the toString method. This method isn’t actually called in the script but I wanted to illustrate what a simple Groovy String (GString) looks like. The method has an implicit return (as the string is the last statement in the method). The String has references to the properties in the class. These properties are enclosed by ${}.

8
9
10
11
12
13
14
15

class Attendee {
  String name
  String lastName
  String email
  String origin
 
  public String toString() {"Name:${name} Last name:${lastName} eMail:${email} origin:${origin}"}
}

The next few lines of code construct new instances of our Attendee class, one for each attendee. Normally these would come from some sort of datasource like a database or something but to keep this example simple, they are just hardcoded here. There are a few things of interest in this code. The first thing to note is that the attendees variable is dynamically typed. It is constructed using an ArrayList that is typed. This is really just to illustrate that Groovy does support Java generics. A typical declaration of a list in groovy would be def attendees = [] the [] are shorthand for new empty ArrayList().



The next interesting feature is the << construct. This is the equivalent of attendees.add().



The last thing to note in this example is the way we’re constructing the Attendee class. We have a comma separated list of values that are prefixed by property names. Notice that in our class definition we don’t have a constructor. This is one of the nice features of Groovy, named parameters.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

def attendees = new ArrayList<Attendee>()
 
attendees << new Attendee(name: "Peter", lastName: "Pilgrim", email: "pp@example.com", origin: "IAD")
attendees << new Attendee(name: "Joel", lastName: "Neely", email: "jn@example.com", origin: "MEM")
attendees << new Attendee(name: "Dianne", lastName: "Marsh", email: "dm@example.com", origin: "DTW")
attendees << new Attendee(name: "Carl", lastName: "Quinn", email: "cq@example.com", origin: "SJC")
attendees << new Attendee(name: "Dick", lastName: "Wall", email: "dw@example.com", origin: "SJC")
attendees << new Attendee(name: "Joe", lastName: "Nuxoll", email: "jn@example.com", origin: "SJC")
attendees << new Attendee(name: "Bill", lastName: "Pugh", email: "pp@example.com", origin: "SJC")
attendees << new Attendee(name: "Dave", lastName: "Briccetti", email: "db@example.com", origin: "SFO")
attendees << new Attendee(name: "Todd", lastName: "Costella", email: "tc@example.com", origin: "YYC")
attendees << new Attendee(name: "Ståle", lastName: "Undheim", email: "su@example.com", origin: "FRA")
attendees << new Attendee(name: "Eirik", lastName: "Bjørsnøs", email: "eb@example.com", origin: "MUC")
attendees << new Attendee(name: "Andrew", lastName: "Harmel-Law", email: "al@example.com", origin: "EDI")
attendees << new Attendee(name: "Oliver", lastName: "Gierke", email: "og@example.com", origin: "ORD")
attendees << new Attendee(name: "Joe", lastName: "Sondow", email: "js@example.com", origin: "LGA")
attendees << new Attendee(name: "Fred", lastName: "Simon", email: "fs@example.com", origin: "ORD")
attendees << new Attendee(name: "Daniel", lastName: "Watson", email: "dw@example.com", origin: "ATL")

The next section is an implementation of a SwingBuilder. Builders are a pretty common idiom in Groovy. There are MarkupBuilders, AntBuilders and others including a SwingBuilder. The SwingBuilder abstracts a lot of the nasty complex requirements for building a rich user interface in Java. Swing is the desktop UI library. It’s very powerful but can also be very complex to use. The SwingBuilder provides a very elegant abstraction on what turns out to be a complex model. One of the great things about the SwingBuilder (and all Builders for that matter) is that in just reading the code, it’s quite apparent what the user interface is going to look like. We start with a Frame. Within the Frame we have a panel and within the panel we have a button and a label. We have a second panel that contains a table and thrid panel that contains the Google Map wiget. The equivalent swing code to implement this would be many more lines of code probably two or three times the amount of code I would guess. The other thing is that it would be harder to visualize the layout of the application with standard swing code. With the builder implementation, we can see how the components are nested within each other.



I’ll talk about the {…} code behind the Refresh Button and the table in a second. Before we leave this code I wanted to talk a bit about the Map component. The Google Map component is based on some fine work by Josh Marinacci that can be found at java.net JXMapViewer.The interesting thing with respect to this example is that any Swing component can be wrapped by a widget call in the builder. This provides a very nice mechanism for reusing existing swing classes within the builder pattern.

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

def swing = SwingBuilder.build {
  frame(title: "Java Posse Roundup 2009", pack: true, show: true, defaultCloseOperation: EXIT_ON_CLOSE, id: "frame") {
    borderLayout()
    panel(constraints: NORTH) {
      boxLayout()
      button(text: "Refresh", actionPerformed: {
        doOutside {...}
      })
      label(id:"status")
    }
    panel(constraints: CENTER) {
      borderLayout()
      table() {...}
    }
    panel(constraints: SOUTH) {
      borderLayout()
      scrollPane() {
        widget(new JXMapKit(), defaultProvider: JXMapKit.DefaultProviders.OpenStreetMaps, dataProviderCreditShown: true, id: "map")
      }
    }
 
  }
}

Aside from the structure of our application, the most interesting code in the builder can be found in the actionPerformed closure. This closure will be called when the Refresh button is clicked. There is quite a bit going on in a very few lines of code. The first thing of note is the doOutside method that takes a closure. Quite simply the code in the closure will get executed in a separate thread. How cool is that? Within the closure we iterate over the attendees collection. For each entry in the collection we make a call to the Yahoo Geo Service. Many thanks to my friend Ido Green for introducing me to YQL via his lightning talk. The XmlSlurper class is a handy means for parsing XML content. The query we’re composing takes the origin airport {it.origin} and returns an xml document that contains a bunch of geographical information for the airport. In our case, we’re only interested in the latitude and logitude. We pull those values out of the resulting document and then construct a WayPoint. The WayPoint object is present in the JXMapViewer package and is relly the only thing we need to construct a pin point on the map.

43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

      button(text: "Refresh", actionPerformed: {
        doOutside {
          def waypoints = new HashSet<Waypoint>()
          attendees.each() {
            def url = "http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20geo.places%20where%20text%3D%22${it.origin}%22&format=xml"
            status.text = "Looking up Airport: ${it.origin}"
            def doc = new XmlSlurper().parse(url)
            if (doc.results) {
              def latitude = doc.results.place[0].centroid.latitude.toString()
              def longitude = doc.results.place[0].centroid.longitude.toString()
              waypoints << new Waypoint(Double.valueOf(latitude), Double.valueOf(longitude))
            }
          }
          WaypointPainter painter = new WaypointPainter();
          painter.setWaypoints(waypoints);
          map.getMainMap().setOverlayPainter(painter);
          status.text =""
        }
      })

The last thing of note is the table entry. The table has a tablemodel which is constructed using the list of attendees. The model itself is very simple and consists of a propertyColumn that has a constructor that takes the column title and the name of the property to display. If you’ve attempted to implement a tablemodel in java (even a read only one like this one), I’m sure you can appreciate the brevity and cleanliness of this implementation.

67
68
69
70
71
72
73

      table() {
          tableModel(list: attendees) {
            propertyColumn(header: 'Name', propertyName: 'name')
            propertyColumn(header: 'Last Name', propertyName: 'lastName')
            propertyColumn(header: 'EMail', propertyName: 'email')
            propertyColumn(header: 'Origin', propertyName: 'origin')
          }

That’s it. 87 lines of Groovy goodness that renders a Google Map in a swing app, utilizes YQL to resolve geo location information for airports.

The source and external libraries that are required to run this application are available here. You’ll need Groovy installed. This archive has idea project files included. If you use eclipse or netbeans you’ll have to add the three external libraries to your project manually.

jpr09.zip