The problem is that getting familiar is a path strewn with brambles and holes full on punji sticks. One of the bigger holes is the event dispatch thread (EDT) – everything Swing related should take place on the EDT (even initialisation, under the latest Sun guidelines). When you’re trying to keep the UI fluid it’s all too easy to break the rule – hence, aspects to the rescue!

This topic has been covered by many before, including Alexander Potochkin and Anders Prisak – however, I found their solution needed a little tweaking to be used in our environment. In particular, they had missed two cases we cover – SwingUtilities and SwingWorker.

So, here’s the tweaked aspect. safeMethods now includes a few extras.

package org.infernus.swing.aspects;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

import java.awt.*;

@Aspect
public class EDTCheck {

    @Pointcut("call (* javax.swing..*+.*(..)) || "
            + "call (javax.swing..*+.new(..))")
    public void swingMethods() {
    }

    @Pointcut("call (* javax.swing..*+.add*Listener(..)) || "
            + "call (* javax.swing..*+.remove*Listener(..)) || "
            + "call (* javax.swing..*+.getListeners(..)) || "
            + "call (* javax.swing..*+.revalidate()) || "
            + "call (* javax.swing..*+.invalidate()) || "
            + "call (* javax.swing..*+.repaint()) || "
            + "target (javax.swing.SwingWorker+) || "
            + "call (* javax.swing.SwingUtilities+.invoke*(..)) || "
            + "call (* javax.swing.SwingUtilities+.isEventDispatchThread()) || "
            + "call (void javax.swing.JComponent+.setText(java.lang.String))")
    public void safeMethods() {
    }

    @Before("swingMethods() && !safeMethods() && !within(EDTCheck)")
    public void checkCallingThread(final JoinPoint.StaticPart thisJoinPointStatic) {
        if (!EventQueue.isDispatchThread()) {
            System.err.println("Swing EDT violation: " + thisJoinPointStatic.getSignature()
                    + " (" + thisJoinPointStatic.getSourceLocation() + ")");
            Thread.dumpStack();
        }
    }
}

Once it’s built, we just need to weave it – I’ve already got compile-time weaving configured for Spring @Configurable support, so just add the JAR containing the aspect as a weaveDependency and then the magic happens.

Now, if a Swing call is made off of the EDT, you’ll get complaints:

Swing EDT violation: String javax.swing.JTextArea.getText() (YourSwingClass.java:98)
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1224)
        at org.infernus.swing.aspects.EDTCheck.checkCallingThread(EDTCheck.java:55)
     ... and so on

Black magic? Perhaps. Time will tell. But first we had to get it set up anyway.

In theory, this is simple. You have two choices: runtime or compile-time weaving. Compile-time means changing your build scripts. Runtime means either using a compliant classloader (WLS, for instance) or changing your JVM parameters (nasty for deployment). Given our lack of desire for deployment pain compile-time seemed the obvious choice.

As always, there was a Maven plug-in. As always, it didn’t work. At least not with Spring 2.5.4. It turns out that Spring 2.5.4 broke compatibility with AspectJ 1.5.4. Worse, Spring’s POMs were broken and it still depended on this incompatible version. So, task one: upgrade to Spring 2.5.5.

Secondly, the Maven plug-in still broke. So, check it out, change the version number and the AspectJ version, compile & upload to our internal repository. Task two: hack the Maven plug-in. I have a growing suspicion that this is a standard part of the Maven workflow.

Now, the easy bit – configure your POM. Except the examples need a bit of tweaking, not least because Java 5 is now old hat. Try the following:

<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjrt</artifactId>
    <version>1.6.0</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
    <version>2.5.5</version>
</dependency>

And:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <version>1.0-st</version>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>

        <showWeaveInfo>true</showWeaveInfo>
        <verbose>true</verbose>
        <proceedOnError>false</proceedOnError>

        <weaveDependencies>
            <weaveDependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
            </weaveDependency>
        </weaveDependencies>

        <aspectLibrarys>
            <aspectLibrary>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
            </aspectLibrary>
        </aspectLibrarys>
    </configuration>
</plugin>

Change the plug-in version number as required, of course.

Finally, step four: pimp your application. You’ll need the following in your Spring configuration:

<context:spring-configured/>

Right, after all that you can start the @Configurable love. Create your bean:

package com.signtechno.example;

@Configurable
public class DummyBean {
    private int value;

    public void setValue(final int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

Create a Spring prototype:

<bean class=“com.signtechno.example.Dummy” scope=“prototype”>
    <property name=“value” value=“17”/>
</bean>

Create your logic:

final DummyBean dummyBean = new DummyBean();

And voila, dummyBean.getValue() == 17. Wasn’t that easy?