• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How is it better?

 
Ranch Hand
Posts: 4632
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 15510
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Michael,

I don't know Griffon, but I just quickly went over the user manual and it looks too much work for me. It's a framework on top of a framework in a language based on Java... to do stuff in Java.

If you're comfortable with Swing, use that. I have the feeling Griffon was designed for people who never got into Swing.
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Griffon reduces the verbosity of the code.
Makes it easy to develop GUI applications.
And provides a framework like Grails for Desktop Application development.
 
author
Posts: 47
VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Cheers,
Andres
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Michael Dunn wrote:


(pinches self)

No, I'm not dreaming.

Good to see you back, Michael!
 
Andres Almiray
author
Posts: 47
VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

Cheers,
Andres
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

Item #4. Threading in Swing apps is hard.


No it's not. At least, not when you know about how the EDT works.

I'm not trying to bash your book (far from it), but the Swing threading model is, in my opinion, not a reason to move away from Swing.
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Andres, this makes it more clear for me too.
 
Andres Almiray
author
Posts: 47
VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:

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.

Cheers,
Andres
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic