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.
Item #1, fixed with something like this http://jira.codehaus.org/browse/GRIFFON-44
Now you can iterate over a ListModel, or ComboBoxModel or even a TableModel like this
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.