Andres Almiray on Griffon: The Road Behind and the Road Ahead

DZone 's Guide to

Andres Almiray on Griffon: The Road Behind and the Road Ahead

· Java Zone ·
Free Resource
DZone is celebrating the success of the Griffon framework as it nears its fifth major release,  and there's no better way to celebrate than with our newest Refcard, Getting Started with Griffon!  DZone took some time to reflect on Griffon's history and where it's headed with the project's co-founder and development lead, Andres Almiray.  He said that today marks the fourth year anniversary since he started using Groovy.

Griffon is a Grails-like application framework for developing desktop applications in Groovy. Griffon follows the Convention over Configuration paradigm, paired with an intuitive MVC architecture and a command line interface.  It defines a simple yet powerful application life cycle and event publishing mechanism.  Grails developers should feel right at home when trying out Griffon. Many of Grails' conventions and commands are shared with Griffon.  Seasoned Java developers will also be able to pick up the pace quickly, as the framework relieves you of the burden of maintaining an application structure, allowing you to concentrate on getting the code right.

DZone:  What were the original motivations and inspirations that led to Griffon?  

Andres Almiray:  The Griffon founders had a lot of combined experience on building Java Swing applications, be it regular desktop or RIAs, so they basically knew many of the pain points that a developer will encounter when creating such applications. Each one on his own time and for his own reasons gravitated towards Groovy and Groovy's SwingBuilder. They found that both gave an energetic boost to building RIAs however something was still amiss: a coherent, intuitive and fun way to build the applications; this is where Griffon's story gets intertwined with Grails.

Grails is a full stack web application development platform, and as such provides many features that increase productivity and make programming fun again, but it does so for web applications only. Griffon aims to provide the same benefits but for RIAs and desktop applications, and it does so by following Grails in spirit but not on its whole implementation.

The reason for this split is that Griffon can build, package and deploy an application in 3 modes: standalone, applet and webstart.  Applications deployed in the last 2 modes must be as small as possible in download size, thus bundling Spring and its required dependencies was not an option. Another point of difference between the two platforms is that Grails applications are optimized for a request-response cycle, whereas Griffon applications are driven by any communication cycle the developer desires.

I should close with a small note, developers that do need Spring at runtime can install a plugin in order to get Spring and its required dependencies. Spring support in Griffon via this plugin closely mirrors the one found in Grails.

DZone:  In what areas of desktop application development does Griffon excel?

Andres:  Griffon helps you in all areas of desktop application development. Its build system takes care of automating repetitive tasks, for example it can bootstrap a working application in seconds. It can also package and deploy applications in 3 modes without touching a single line of configuration. Testing a desktop application can be tedious at times, Griffon makes sure that is not the case. And if some functionality is not provided by default then it's probably just a plugin install away.

DZone:  Can you think of any great examples of Griffon apps?

Andres:  Most of the Griffon applications that I'm aware of are those that are built to replace or enhance an existing tool. These tools are mostly of internal use in enterprises. Griffon is also used as a means to prototype applications. And of course you'll find a growing set in the open source space. We hope one of these days someone will publish the news of a customer facing Griffon application available in the wild.
DZone:  Today Griffon seems pretty popular on DZone.  How much has the user base grown over the project's history?

Andres:  I'd say it has grown slow but steadly. One of the often cited drawbacks for adoption is the lack of documentation. We're closing that gap now with the immediate availability of the Griffon Refcard =) The last stable release (0.3.1) saw the debut of the Griffon Guide, the first stop to learn all about Griffon's command line interface, testing facilities, plugin system and more.

DZone:  What's new in Griffon 0.9?

Andres:  Lots and lots of new things!  First, the build system has been synchronized with Grails 1.3.2.  This means that the following features are now available: dependency resolution DSL, custom build listeners, testing facilities, packaging and plugin enhancements.  It is the testing facilities that excite me most from the buildtime perspective as they enable a wide range of options, most notably the means to port Grail's Spock plugin to Griffon.  From the runtime perspective, the major changes are related to the location of Swing classes, which pose a backwards compatibility breakage (intentional). These breakages combined with the turbo charged buildtime features prompted the upcoming release to jump from version 0.3.1 to 0.9.

DZone:  What does the feature roadmap for Griffon 1.0 (if that's the next major version) and beyond look like?

Andres:  Quite frankly, bug fixes and rock solid documentation.  Most of the features that comprise a 1.0 release have already found their way into Griffon core.  There are several buildtime/runtime improvements that can be delivered via plugins, given that the core has stabilized itself pretty fast.  Beyond 1.0 lies better integration with UI toolkits other than Swing (like SWT and JavaFX).  Work on this area has already been started via plugins.  Another interesting point is OSGi integration which we keep an eye on but have yet to write some code in that direction.

Tantalizing details, Andres!  Go get the Griffon Refcard now!

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}