Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 221 posts at DZone. You can read more from them at their website. View Full User Profile

Trying Griffon and Loving It

04.05.2012
| 3581 views |
  • submit to reddit
Admittedly, Java’s Swing is a much under-estimated technology for intra-enterprise applications. I’ve had the chance to work for some enterprises that used it and I’ve very much admired the delivered applications. At that time, they were far superior in usability compared to those meager web-applications (even though the gap is closing). That is not to say that Swing is a silver bullet, far from it. In my numerous tries, I’ve found it lacking in some areas:
  • Like so many APIs in Java, Swing offers low-level API only. It’s up to the developer to create or choose a higher-level framework.
  • I’m not fond of the verbosity argument, but in Swing’s case, writing (and reading) code is long and tiresome.
  • Finally, Swing lacks binding between the UI component and its underlying value. At least one try I know of has been made in this direction but it’s frozen solid since a couple of years, with sadly no hop of going further.

Griffon discovery

Thus, it’s only natural that when I saw Andres Almiray‘s Griffon presentation at the Geneva JUG, I was awestruck. Griffon is a framework for the Groovy scripting language, which runs on top of the JVM. It’s concise and provides:

  • A conceptual MVC framework
  • Additional features wrapped around common Java API (such as collections) through Groovy
  • Really easy bidirectional binding

A typical Griffon’s view code looks like that:

application(title: 'form',
  pack: true,
  locationByPlatform:true,
  iconImage: imageIcon('/griffon-icon-48x48.png').image,
  iconImages: [imageIcon('/griffon-icon-48x48.png').image,
     imageIcon('/griffon-icon-32x32.png').image,
     imageIcon('/griffon-icon-16x16.png').image]) {
  borderLayout()
  panel(constraints: CENTER, border: emptyBorder(6)) {
    gridLayout(rows:3, columns:2, hgap:6, vgap:6)
    label 'Name:'
    textField columns:20,
      text: bind(target: model, 'name', mutual: true)
    label 'Last Name:'
    textField columns:20,
      text: bind(target: model, 'lastName', mutual: true)
    label 'Address:'
    textField columns:20,
      text: bind(target: model, 'address', mutual: true)
  }
  panel(constraints: SOUTH) {
    gridLayout(rows:1, cols: 2, hgap:6, vgap:6)
    button('Reset', actionPerformed: controller.reset,
       enabled: bind{ model.resetEnabled })
    button('Submit', actionPerformed: controller.submit,
       enabled: bind{ model.submitEnabled })
  }
}

The good points

Griffon offers many features that are aimed to improve productivity:

  • Griffon is not only a framework but also a toolkit suite. For example, a command-line tool is made available for those that don’t like point-and-click.
  • At the other end of the spectrum, Griffon offers a tight Eclipse integration (if you’ve installed the Groovy plugin beforehand)
  • Both Groovy’s and Griffon’s documentation are riddled with practical examples
  • Groovy is backed by SpringSource, a token of long-term support
  • The Griffon support in the mailing list seems to be very good
  • Once created, your application can be shipped as an applet, a Java Web Start or a standalone application! This is too good to be true!

What could be better

I must confess that I dived right in into Griffon without taking time to read much documentation before, so some of these points could be a lack of knowledge on my part. Still, others are valid in all cases:

  • An application developed with Griffon has a high startup time (a few seconds). It may not be a problem, and is probably because it uses Groovy, but it can be an argument against Griffon in some contexts.
  • I have found no way to integrate with Maven: building with Maven uncovers some unavailable dependency error. For m2e, the newer version of m2eclipse, some lifecycle phases are not covered so that it’s unusable as is. I understand the Groovy people have their own build tool (Gant), but some of us mortals still use Maven ;-)
  • Griffon seems to be the work of Andres Almiray alone (kudos to him), but in the long term, it sheds some doubts on the longevity of the framework

My own try

Since nothing is better than the proven try-it-yourself approach, I developed an embryo of a JAR manifest file reader. The first results can be found on Github: Groovy and Griffon experts are welcomed to give me their feedback… and to fork the code to get further.

 

 

Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)