Griffon: JavaFX for the Enterprise.

A few weeks ago I presented a talk on JavaFX and Griffon in Linz hosted by eJUG. A couple of Griffon (Swing and JavaFX) applications were shown on stage, with two of them going toe to toe in showing how easy is to integrate JPA into a desktop application no matter the UI toolkit of choice. I'm going to reproduce both applications right here in order to show the similarities and differences between choosing Swing or JavaFX when building an application with Griffon. Let's get started.

Create the applications
The first step is to create both applications. Swing being the default toolkit of choice at the moment makes it for a simple command call, like the following one

Configuring JPA
The following step must be executed in both applications. What we'll do is install the JPA plugin, create a JPA entity, configure the default persistence unit, and bootstrap some data when the application starts.
Alright, installing the JAP is done in the following way

Adding Swing / JavaFX
The following screenshots show the Swing and JavaFX versions. you can appreciate both have the same set of elements though they look slightly different. Can you guess which is the JavaFX one? That's right, the one with the non-native look (pay no heed to the title)

The views have references to their corresponding models and controllers. The models hold a reference to an observable list that will be used to update the table. In the case of Swing we'll rely on the excellent GlazedLists project (for which there's a plugin of course). Here's how the model looks
griffon-app/models/sample1/Sample1Model.groovy
package sample1 import data.Person import ca.odell.glazedlists.EventList import ca.odell.glazedlists.BasicEventList import ca.odell.glazedlists.SortedList class Sample1Model { EventList people = new SortedList(new BasicEventList(), {a, b -> a.id <=> b.id} as Comparator) }
For the JavaFX version the code turns out to be much simpler as observable lists are baked right into the JavaFX APIs. The JavaFX model looks like this
griffon-app/models/sample2/Sample2Model.groovy
package sample2 import javafx.collections.FXCollections class Sample2Model { List people = FXCollections.observableList([]) }
Now for the final piece, we must provide a suitable implementation for the controller actions. You may recall from the views that there are 2 actions in the controller: one to load the data in the table, the second to clear the table. And here's where things get really interesting as the code I'm about to show is practically the same, no matter if you're dealing with Swing or JavaFX
griffon-app/controllers/sample1/Sample1Controller.groovy
package sample1 import data.Person import griffon.transform.Threading import javax.persistence.EntityManager import javax.persistence.Query class Sample1Controller { def model def load = { withJpa { String persistenceUnit, EntityManager em -> List<Person> tmpList = [] tmpList.addAll em.createQuery('select p from Person p order by p.id').resultList execInsideUIAsync { model.people.addAll tmpList } } } @Threading(Threading.Policy.SKIP) void clear(evt) { model.people.clear() } }
Don't be fooled by the apparent lack of UI code found in the controller actions, as Griffon controllers follow some rules regarding how threading should work. For starters all controller actions are executed outside of the UI thread (whether that's the EDT in Swing or the JavaFX UI thread in JavaFX only the specific toolkit plugin cares). It's then safe to query the database using the JPA APIs inside the load action, however once the data has been computed we must update the model inside the UI thread as that change will trigger an update on the visual components bound to the people list (the JTable and the TableView respectively). The second action, clear, updates the contents of the model directly, and as such it should be done in the UI thread already, no need to jump to another thread just to come back immediately to the UI thread; this is why we applied an annotation that instructs the compiler to leave this action untouched in terms of thread management code injection.

If the usage of an application framework like Griffon was dubious at first I hope you think differently now. Apart from some toolkit specifics found in the View and Model, the application remains the same no matter the toolkit you're targeting. This proves to be of great advantage for developers willing to give JavaFX a try, as starting with Swing today doesn't mean rewriting the whole application with JavaFX later. Compound the growing list of plugins available to Griffon applications and you're up for a fun ride when developing desktop applications for the JVM.

In terms of numbers both applications are very close. These are the stats for the Swing version
+----------------------+-------+-------+ | Name | Files | LOC | +----------------------+-------+-------+ | Models | 1 | 9 | | Views | 1 | 22 | | Controllers | 1 | 19 | | Lifecycle | 5 | 3 | | Groovy/Java Sources | 1 | 13 | | Unit Tests | 1 | 13 | | Configuration | 2 | 38 | +----------------------+-------+-------+ | Totals | 12 | 117 | +----------------------+-------+-------+
Whereas the JavaFX version sports these numbers
+----------------------+-------+-------+ | Name | Files | LOC | +----------------------+-------+-------+ | Models | 1 | 5 | | Views | 1 | 25 | | Controllers | 1 | 19 | | Lifecycle | 5 | 0 | | Groovy/Java Sources | 1 | 13 | | Unit Tests | 1 | 13 | | Configuration | 2 | 38 | +----------------------+-------+-------+ | Totals | 12 | 113 | +----------------------+-------+-------+
Not bad, huh? Full source code for both applications can be obtained from this link.