Griffon: Threading Management take II

There's a previous discussion on threading management in Griffon that explains what Griffon can do to help you write well behaving Swing applications. The options for better threading management have been updated in the most recent release (0.9.2-rc1). The following is a quick summary of what you can do now.

Automatic execution of Controller actions outside of the UI thread
How many times have we seen a sample Java desktop app follow this pattern
public class PoorlyWrittenDesktopApplication { public static void main(String[] args) { PoorlyWrittenDesktopApplication app = new PoorlyWrittenDesktopApplication(); app.show(); } private JFrame frame; public void show() { if(frame == null) { frame = new JFrame("PoorlyWrittenDesktopApplication"); frame.getContentPane().add(initGUI()); } frame.setVisible(true); } private JComponent initGUI() { JButton button = new JButton("Long running operation"); button.addActionListener((new ActionListener() { public void run() { fetchDataFromServer(); } )); return button; } private void fetchDataFromServer() { // execute a network call or a database query } }There are two problems here. First the UI is built in the same thread as the Main thread, this is a big no-no when working with Swing; you must create all components inside the EDT. The second problem is the button callback. As the name suggests it will load a (potentially huge) set of data from the server (a file, database or network call). Given that the callback will be executed in the same thread that spun it (yes, that is the EDT) the UI will be frozen for the duration of the callback's execution. We can solve these problems by wrapping show() with SwingUtilities.invokeAndWait and spawning a new Thread (or use an ExecutorService) inside fetchDataFromServer(), like this
public class BetterWrittenDesktopApplication { public static void main(String[] args) { BetterWrittenDesktopApplication app = new BetterWrittenDesktopApplication(); app.show(); } private JFrame frame; public void show() { SwingUtilities.invokeAndWait(new Runnable(){ public void run() { if(frame == null) { frame = new JFrame("BetterWrittenDesktopApplication"); frame.getContentPane().add(initGUI()); } frame.setVisible(true); } }); } private JComponent initGUI() { JButton button = new JButton("Long running operation"); button.addActionListener((new ActionListener() { public void run() { fetchDataFromServer(); } )); return button; } private void fetchDataFromServer() { new Thread(new Runnable(){ public void run() { // execute a network call or a database query } }).start(); } }Much better now. But what does this have to do with Griffon and its Controllers? Well, the equivalent code in Griffon already takes care of problem #1, every single View is automatically executed inside the EDT and all windows are shown/hidden inside this thread as well; you don't need to do a thing for this to happen. The second problem can easily be solved by resorting to doOutside or execOutside as you prefer (they do the same thing). This leaves us with the following Griffon snippets, the View
package sample application(title: 'Griffon', pack: true) { button('Long running operation', actionPerformed: controller.fetchDataDromServer) }And the Controller
package sample class SampleController { def fetchDataFromServer = { execOutside { // execute a network call or a database query } } }Not bad. However starting from 0.9.2-rc1 you can eliminate the call to execOutside altogether, as Controller actions are automatically executed outside of the EDT now. This trick relies on AST injection done at compile time. This feature can be disabled (as explained in section 8.1.1 of the Griffon Guide) given that it breaks behavior compatibility with previous releases.

What constitutes a Controller action? These are the rules applied to each closure property and method of a Controller class to determine if it's an action or not

• it's name should not match an event handler, i.e, should not start with on.
• it must have the public access modifier if it's a method.
• it's signature should not match any of the methods defined in griffon.core.GriffonController.

Inject threading management to any class
SwingBuilder gave us edt, doLater and doOutside. Griffon 0.9 added a few more variants. Subsequent releases enabled direct usage of exec* in life-cycle scripts and addons. Griffon 0.9.2-rc1 expands what you can do with a handy new AST transformation: @Threading.

Without this feature you would need to write the following code
import griffon.util.UIThreadHelper class RandomObject { void doSomethingOutsideEDT() { UIThreadHelper.instance.executeOutside { // business logic } } void doSomethingInsideEDT() { UIThreadHelper.instance.executeAsync { // update UI } } }The code is not so bad thanks to Groovy's closure support, but what if we let the compiler write the wrapping code for us? That's precisely what @Threading does. Compare with
import griffon.util.Threading class RandomObject { @Threading void doSomethingOutsideEDT() { // business logic } @Threading(Threading.Policy.INSIDE_UITHREAD_ASYNC) void doSomethingInsideEDT() { // update UI } }The code looks a bit cleaner now. And best of all you can apply it to any Groovy class, not just Griffon artifacts. Nice! Too bad AST transformations only work with Groovy sources, it would be great if Java sources had similar support. Oh wait, but they can, if you're willing to consider Project Lombok. As a matter of fact there's an experimental branch of Griffon 0.9.2 that uses Lombok to enable the usage of @Threading with Java sources, see this link.

Event publishing outside the UI thread
In case you didn't know Griffon has a basic event bus baked right into core. Previous releases made sure that event publishing would happen outside of the EDT always. But that restriction proved to be a detriment in some cases. The new rule for event publishing is that event handlers will be called in the same thread as the event emitter. There's a new method that retains the original behavior, that is, inform event handlers outside of the EDT. The latter is now the optional method while the former has moved to the official one.