Griffon, the Groovy framework for Swing developers, was released a few weeks ago. Promising a consistent source structure for Swing applications, as Grails has done for the web, it also potentially provides an alternative application framework to those provided by Spring RCP, Eclipse RCP, and the NetBeans Platform. Clearly, this is a very interesting development. Let's find out more from Griffon's creators, James Williams, Danno Ferrin, and Andres Almiray.
Firstly, can you each introduce yourselves?
Andres: I'm a Java developer by day and a Groovy developer by night, interested in all things Swing. (Click here for an earlier interview on Groovy Zone with Andres.)
James: I've been a Groovy developer for about two years now and prior to Griffon, my major claim to fame was SwingXBuilder, a DSL in the mold of SwingBuilder, that brought easy access to SwingX components to Swing. Out of the three of us, I'm probably the most idealistic, Danno is like the sensei master, always with a reasoned, calm demeanor, and Andres is somewhere in between. (Click here for an earlier interview on Groovy Zone with James.)
Danno: I'm Danno Ferrin and I currently have only one Hawaiian shirt in my closet, and I have never seriously considered a career in Law enforcement. I enjoy hacking at code like some people enjoy reading novels, playing video games, or sports. So as a professional software developer I am basically monetizing my hobby. (Click here for an earlier interview on Groovy Zone with Danno.)
You've created something called "Griffon". Can you explain in 1 sentence what that is?
James: Griffon is simplified, sensibly structured Swing.
Danno: Grails for the Desktop.
Andres: Best thing since sliced bread? No, really. Griffon is agility for Swing application development.
What is the Number One Reason that someone should start playing with it today?
James: The source code of every Griffon app has the same structure.
Andres: Griffon is still in its infancy, but its lineage can be trace to the Grails framework (not only in spirit but in code too) which means that anyone familiar with Grails for web application development can pick up Griffon and create a desktop application in minutes.
Danno: It makes the process of building a Swing application more like developing a Web application. It encourages separating the code by purpose. The dynamic features of Groovy are also used to make appropriate sections of code more fluent for their purpose, particularly in the view layer.
Can you remember and describe the 1st moment that you thought of creating this framework?
James: If I remember correctly, it was shortly after I completed SwingXBuilder (SXB) last year. Sometime in September I think. During that summer, whilst I was in the process of creating SXB, Andres rewrote how builders are created (with FactoryBuilderSupport) and created GraphicsBuilder. There were a flurry of e-mails back and forth about Groovy and Swing since it was becoming apparent that Groovy and Swing was starting to grow legs, so to speak. We eventually got together on Skype and talked about the meta-objectives we wanted the as-yet unnamed project to accomplish. I believe that was about that time when the concept of a GUIBuilder, a builder that can access widgets from several different builders, first came up. I picked it (the name) because it was a nice double entendre, either GUI (Graphical User Interface) Builder or Groovy User Interface Builder. I'm the guy who names things.
Danno: Andres, James, and I were having a Skype conference almost a year ago discussing some of the things that Groovy could do with regard to Swing. One of the concerns was that we were making many one-off builders for the various Swing component libraries, and getting them to merge into one builder was already hitting the combinatorial limit of single inheritance (n=3). So the idea of an UberBuilder was hatched that would include all of these widget builders, or some of them, or however many of them the user wanted. While at the time the endgame that became Griffon wasn't in my mind, the core enabling technology was envisioned as a result of that call. The rest of the idea started forming a few months later, but without the UberBuilder it wouldn't look quite like it does now.
Andres: I'd have to go back to my web app development days, when Struts was the uncontested king of web frameworks. We were quite happy with the structure the framework provided, we knew which levers to pull and which switches you should throw to make the app work (or not), but the thing is that a day came when a big project landed in our lap and it wasn't related to anything we'd done before. We had to deliver a desktop app (distributed over a VPN) which prompted the following question: where is Struts4Swing? We couldn't find a single framework that fulfilled the same promises as Struts but in the desktop arena. I believe Griffon covers that need, but in a modern way thanks to its Grails heritage. Oh, and, back to my story, we ended up rolling our own craptaculous Swing framework, as many developers did in those days.
Can you list all the features that you'd mention in a brochure, for example?
Danno: Umm... I'm a programmer, not a marketer. That's why I'm doing this as open source rather than as a VC company. Andres has more of a head for marketing than I do.
Andres: Here you go:
- Common structure. Every component of the MVC pattern has its own place and conventions, one might venture to say "well-proven", coming from its Grails heritage
- Agility. Due to the leverage of the Groovy programming language.
- Interoperability. Mix and reuse any Java/Swing component/library.
- Easy deployment. A single Griffon project can be deployed as an applet, a webstart application or an standalone application by choosing the appropriate package command, no extra configuration required.
What are your 2 personal favorite features of Griffon?
James: Built-in targets for webstart and applets and intermingling of builders.
Andres: The CompositeBuilder, which is the one that does all the magic behind the scenes to mix&match all builders into a single cohesive unit that is still configurable Secondly, the structured conventions that guide you to a better design of your application
Danno: The UberBuilder composing multiple builders and the auto-packaging into jars and JNLP files suitable for applications, web apps, and applets.
What was it like to create this framework (in terms of time taken, energy, fun factor)?
Danno: When writing code like this there are two major milestones you look forward to. The first is where your 'happy path' runs through the framework correctly the first time. The second is when you package those pieces together and get it into the SCM repository for others to see. The first is a blissful sense of accomplishment and the second is validation by other people that you really did do it and it wasn't just sleep deprivation when you thought you hit the first milestone.
Andres: Programming in Groovy is fun! even when you get some 'nasty' meta-programming errors (it means you need to learn a bit more :-)) we have been looking at different pieces of the puzzle for more than a year, sometimes a simpler task (like abstracting FactoryBuilderSupport from the original SwingBuilder) turned out to be the domino that started a chain reaction that culminated with the CompositeBuilder, a wicked idea from Danno.
Did you end up developing anything that you'd never thought of when you started?
Danno: Having the demo app be a twitter application was a surprise. I re-purposed the code that was used in the JavaOne script bowl and split the file across the build directory. Having a concrete and real-world demo app to develop the framework helped a lot.
Andres: Frankly I didn't expect you to pick up the framework and provide initial support for it on NetBeans 24 hours after its release! But the framework is still evolving, I guess we will have to wait and see for a few months more.
The framework is for Groovy developers. Could Java developers use it too and how?
James: Definitely. Groovy doesn't function any differently when you intermingle Java and Groovy files. Often the path to Groovy is a gradual evolution from Groovy code in a Java accent to true Groovy code. Java developers would need to learn one of the builders for layout purposes. Any custom components written in Java code can be just dropped in without any major modifications.
Danno: Java developers can absolutely use it. The only parts that must be groovy are the configuration files and the view files. And those can be thought of more as DSLs rather than as groovy source code. The Groovy joint compiler is used everywhere we compile groovy code, so every where you see a groovy file with a class in it you can substitute a java file for it. There is a bit more you will need to do in some cases to make things work smoothly, like creating your own bound properties if you want to use model binding. But using Java instead of Groovy makes the most sense in the controller and business logic, which is where the bulk of the code would exist.
Andres: Of course they can, we encourage every single Swing developer to give it a try, no matter if their language of choice is Groovy or not. In theory, you could code all parts of a Griffon application with plain Java, but then you will be missing on the good parts of Groovy, like optional semicolons, closures (yay!), meta-programming and DSL capabilities.
Can you describe Griffon's architecture?
Danno: In, like, what, two sentences? Oops, there goes one, and now two. Drat! The architecture is still evolving. Basically there is a build-time component and a run-time component. The build-time portion is modeled after Grails and Rails, using gant build scripts to generate code and assembling the application based on conventions over configurations. The run-time portion is modeled loosely off of the work I've seen in JSR-296 (appframework.dev.java.net). The lifecycle files in particular are heavily influenced by it. There are some design decisions 296 made that precluded us from just using it directly (namely it's use of singletons and the inability to insert foreign actions into its action framework).
If Grails is targeted at Java EE and Griffon at Java SE, is there room for a Java ME framework on Grails? Or some other framework on Grails?
James: Java ME is a whole lot more difficult, I think. As it stands now [for Griffon], we have to worry about Java 5 and Java 6 issues on the desktop. I couldn't imagine trying to target all the different J2ME profiles without going crazy. I am somewhat envious of the fact that Scala can run on Android though. The fact is that Android's UI structure in code is very similar to Swing. The same applies t oGWT. But each of these uses a stripped-down JVM that would probably make the task difficult.
Danno: One of the things that make Grails and Griffon appear to work like magic in their is judicious use of dynamic language features such as meta-programming. This is precisely what makes it problematic for Mobile Edition. I don't know of any ME profiles that allow for loading bytecode at runtime and reflecting class members and methods, and those two features are essential for meta-programming.
Andres: I'd love to see that but that will require a version of Groovy that runs on Java ME, which is not available as to this day.
Could one say that Griffon lets one refactor the source structure of an application, i.e., the end result will always be the same to the end user? Or does Griffon provide any additional services that the end user would be aware of?
Danno: In my opinion, if an end user can look at an application that has been refactored for Griffon and tell that it is a Griffon application, we have failed. Frameworks are enabling technologies and the end user should be none the wiser about how the developer built the application unless that user has a priori knowledge that a particular framework was used. That goes for any framework and not just Griffon.
Andres: In terms of the end user, the behavior of a non-Griffon application and a Griffon version should be the same, but if you factor in that SwingBuilder and Griffon make it very easy to not fall into the threading traps of Swing, that the code is structured in a way that lets you follow the MVC paradigm you could bet that the ported application will have less glitches. Given the productivity gains the developers (and the QA department if exists) will have more time to fool-proof the application, so the end user will receive a higher quality product after all.
What competing frameworks are there and how does Griffon stack up?
Danno: JSR-296, Spring RCP, NetBeans Platform, Eclipse RCP. The biggest issue currently is that the last two are battle hardened and the first two have had paid development for a couple of years. So my choice of the 0.0 version moniker was more than just a computer science joke. As more people look at it and it gets more real world exposure at that point it may be worth comparing to established frameworks.
James: Griffon is very new. When stacked up against AIR, I would say Griffon doesn't have a first class browser component. Sure, you can use JDIC components but ymmv and JDIC support is strongest for Windows. Hopefully JWebPane can rectify this when it is released. I would also say that Groovy is a scripting language with a funny name. The way you market Groovy to non-developers has to be different to the way you target developers. Scott Davis often describes it as "next-gen[eration] Java." While that description is very succinct, it is equally scary to the non-Java crowd. I think Griffon, with the builders for Swing components that are currently available, lowers the barrier to entry for non-dev creatives to create compelling visual experiences in Java apps with limited amounts of coding.
Griffon also benefits from Groovy's lineage from Java. There's some stuff that doesn't have a "Griffon" way of doing them but can be done the Java way. I recently wrote a post using Carbonado to do ORM. Hibernate or Toplink could also be used but require more configuration files. In general, Java is a platform that has a plethora of libraries. Griffon will greatly benefit from that. AS3, on the other hand, has less choices.
What are the next steps for the framework, e.g., timeline and so on?
Danno: I expect a 0.1 release to align with the release of Groovy 1.6-beta-2 (there are some Grails bugs they have to work out), and another point release when 1.6 reaches FCS. Other point releases will be driven by significant feature adds, such as a plug-in framework and Grails 1.1 GORM support. Reaching 1.0 will be, as always, a marketing exercise. Once we feel we have enough features and there has been enough battle testing then that will be the time to declare a 1.0.
Andres: We are still deciding what should be included in the intermediate releases up to the big 1.0, we encourage all users of the framework to discuss features at the project's mailing lists.
How do I get started!
Andres: Go to the Griffon download page, follow the install instructions and the quick start guide, you should be able to create a Griffon application in minutes! The next step would be to get acquainted with SwingBuilder and its brothers (SwingXBuilder, JideBuilder) to learn more about the available Swing nodes, and then probably create your own nodes too! :-)