This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
first line of 'description' from book link:
"Although several options exist for interface development in Java, even popular UI toolkits like Swing have been notoriously complex and difficult to use.
Griffon, an agile framework that uses Groovy to simplify Swing, makes UI development dramatically faster and easier."
I don't find swing 'notoriously complex and difficult to use' at all, quite the contrary - so, what's in it for me?
OK let's see. Swing is an UI toolkit, and as such it comes with
- a rendering pipeline
- a set of UI components
- options for customizing how components are drawn
- ability to build your own components from scratch or by composition
But you need more than that to build an application, you need:
- a basic and recognizable structure
- the means to build, package and deploy the application
- a way to express optional dependencies (and believe me, you'll have additional dependencies)
- probably shield yourself from the Swing Bane, a.k.a, the Swing threading execution rules
- helper classes that tie things together
And that's precisely what Griffon offers (and more), wrapping all things together with a Groovy DSL cover.
It's true that the Griffon manual covers a lot of ground and topics. Truth is you only need to go through it fully if you really want to know all the gritty details. The basic building block of the framework, an MVC group, was designed to help you build the application organically. It's also true that there are many options you can choose from in Griffon, fact is you can let the framework decide most of the stuff for yourself, that's the power of Convention of Configuration.
Stephan van Hulst wrote:If you're comfortable with Swing, use that. I have the feeling Griffon was designed for people who never got into Swing.
Actually, Griffon was designed by seasoned Swing developers that were tired of writing the same boilerplate all over again, falling through the same traps every single time. What traps?
- lack of JDK5 features: yes, lack of generics and deeper integration with the collections library (ever wanted to iterate over a ListModel as you do with a java.util.List?)
- Swing Application Framework (JSR 296): killed before it got interesting
- Beans Binding (JSR 295): killed as well. The expert group even proposed yet another expression language in order to deal with declarative bindings.
- threading problems. Tell me again, what happens if you call SwingUtilities.invokeAndWait() inside the EDT?
- code verbosity. This one is attributable to the Java language itself
We took all of these things (plus a few more irritating problems) and solved each one of them.
We can't do anything about the standard Swing API but we certainly can enhance the classes via Groovy metaprogramming.
I'm aware you can do this in plain Java but the code wouldn't look as succinct (unless you hide away the wrapping code in statically imported factory methods).
Item #2. Griffon takes inspiration in JSR 296 as a matter of fact. There's a clear application lifecycle manager (and lightweight to boot!).
Item #3. Binding, including both directions is as easy as pie with Groovy and not so difficult in Java. Have a look at sample code from the manual.
Item #4. Threading in Swing apps is hard. It's very easy to shoot yourself in the foot, so what can you do about it? You mitigate the problem with threading facilities. Every single Griffon application has access to correct implementations of threading execution options. Every single Griffon artifact (that is, Models, Views, Controllers, Services (and additional artifacts provided by plugins)) have access to those facilities.
Item #5. What do you do to combat Java's verbosity? Switch to a JVM language that gives you more bang for your buck: you write less and keep the same behavior; that's what Groovy is for in this case. However considering that Groovy is not the only alt JVM lang in town, we support other languages as well: Scala, Clojure, Mirah, Jython and Erlang (all of them just one plugin install away). Not to mention that Java can be used as well, in conjunction with any (or none) of those languages.
So, if plain Swing & Java plus maybe Maven to deal with build/package/deploy/dependency management are good enough to deal with all of these concerns then I guess Griffon wouldn't have been born in the first place.
Andres Almiray wrote: - threading problems. Tell me again, what happens if you call SwingUtilities.invokeAndWait() inside the EDT?
You get an IllegalStateException Error. One that can be prevented by checking EventQueue.isDispatchThread. Nothing hard about that.
Precisely. Not _that_ hard but troublesome. Which means you have to be sure in which thread you're currently on. Which means your code will usually look like this
What Griffon proposes is that you write that code like this
or if you prefer to write in in Java
Follow the same principle for executing code asynchronously inside the EDT (invokeLater) and outside (spawn a new thread or use a ThreadPool). That's what Griffon does for you. That's what an application framework should do for you.
Rob Spoor wrote:
Item #4. Threading in Swing apps is hard.
No it's not. At least, not when you know about how the EDT works.
And yet we keep looking at code sample that open DB connections inside ActionListeners bound to buttons for example. The Swing threading rules are well explained but it's so easy to break them. Granted, Griffon does not claim to have solved the problem completely, developers still must exercise a level of restrain from executing code willy-nilly. Some additional things Griffon does for you are:
- all controller actions are automatically executed outside of the EDT. This execution is scheduled using a ThreadPool configured to make the most of the currently available processors.
- the previous setup can be overridden using either configuration flags or annotations
- threading becomes so important that every single artifact is aware of these concerns and gains the ability to fire executions in the appropriate thread.
And no. I'm not advocating to get away from Swing, far from it.
Joined: Jun 09, 2003
Thanks Andres for the detailed responses/examples, which make sense.
Looks like I'll have to read a bit more of the book than just the description.
Thanks to the others for their replies, much appreciated.
Just looked at my posting history Darryl, wow, it has been a while!
Hopefully I'll get more time to hang around a bit.