Home > Development > Trying Griffon and loving it

Trying Griffon and loving it

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

An 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 })
  }
}

Code taken from Github

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.

email
Send to Kindle
Categories: Development Tags: ,
  1. April 2nd, 2012 at 17:43 | #1

    I’m not a Griffon expert, but agree with your first paragraph. Have you ever heard about JVx? It solves the binding problems and offers a smart API to develop applications. We use it four business critical applications.

  2. April 4th, 2012 at 14:52 | #2

    Hi Nicolas,

    I’m glad you like Griffon so far :-)
    Addressing your concerns on Griffon’s performance and future:

    1. We’re aware that startup time varies from application to application, however we have recently added some features that can help reducing the time, such as disabling the event bus and sipping MVC event triggers for example. We have also moved more code from Groovy to Java thus disabling dynamic method dispatch for internal stuff. But we haven’t finished yet, expect more speed improvements to be added on the road to 1.0, and beyond.

    2. Love it or hate it, Maven is still with us. We have experimental maven support already but we haven’t pushed out to the public yet because we want to push Griffon 1.0 sometime this year, which means making sure the core platform is rock solid. Maven support can (and will) be delivered outside of core when ready.

    3. Griffon is the result of the efforts of several people even though it looks like I’m the major contributor. In the last couple of releases we have added features coming from real projects and real customers The recent build system overhaul for example is the result of deep dive into solving problems found in enterprise applications built with Griffon.

    Cheers,
    Andres

  1. No trackbacks yet.