This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes How is it better? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "How is it better?" Watch "How is it better?" New topic
Author

How is it better?

Michael Dunn
Ranch Hand

Joined: Jun 09, 2003
Posts: 4632
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?
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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.
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

Griffon reduces the verbosity of the code.
Makes it easy to develop GUI applications.
And provides a framework like Grails for Desktop Application development.


Mohamed Sanaulla | My Blog
Andres Almiray
author
Ranch Hand

Joined: Jan 25, 2010
Posts: 47

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
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4571
    
    5

Michael Dunn wrote:

(pinches self)

No, I'm not dreaming.

Good to see you back, Michael!
Andres Almiray
author
Ranch Hand

Joined: Jan 25, 2010
Posts: 47

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
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

Thanks Andres, this makes it more clear for me too.
Andres Almiray
author
Ranch Hand

Joined: Jan 25, 2010
Posts: 47

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

Joined: Jun 09, 2003
Posts: 4632
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.
 
GeeCON Prague 2014
 
subject: How is it better?