The “Break it Down” Blog

Dean Iverson just put together an excellent introduction to JSR 296 (Swing Application Framework) over on his blog.

For those that don’t know, JSR 296 is an attempt to create a simple application framework to build your Swing applications on top of. Word on the street is that it will be part of the Java 7 (JDK 1.7 release) in 18 months or so. Also, it’s not meant to compete with the Eclipse RCP or the NetBeans Platform, but meant to be a simpler platform for smaller applications to build on that may not need the infrastructure of an entire platform.

The approach to the new framework is this in a nutshell:

• Provide lifecycle hooks for start/run/stop (and other stages) of an application and allow developers to easily write code in these hooks to do stuff. For example, after calling launch on your application, you can fill in the method body to the startup method to do something interested.
• Automate binding Swing component values to resource bundles (property files). For example, not only can you store your component labels easily, you can also store other component properties like it’s font style, back ground color and any other property in the same properties file using the variable name as the identifier. Then the application framework will automatically inject all that for you.
• Running tasks asynchronously to the Event Dispatch Thread (EDT) is managed automatically and functionality provided to implicitly disable components that must wait for a task to be done. For example, you click a Search button which fires off a task that doesn’t lock up the UI and disables the Search button so the user can’t keep clicking it, firing off more and more tasks.

I’m sure the framework does more, but this is the gist of what I saw that was slick. The premise of hooking the components and their properties together requires two things:

1. For any class you want to inject resources into, you need to create a sub-package named resources with a properties file in it that has the same name as the class. For example the class com.test.UserForm would have to have a properties file com.test.resources.UserForm.properties in order to have the values mapped.
2. The component that wants to be mapped must be tied to a value in the properties file by using the setName property from the java.awt.Component class. For example searchButton.setName(”searchButton”) would require the properties file had a property that started with searchButton and all properties that were to be set denoted with dot-notation like searchButton.label=Search

To drive the point home, let’s say you have code, in a class named com.test.SearchPanel like this:

JButton searchButton = new JButton();

searchButton.setName(”userSearchButton”);

And let’s say you have a properties file in the package com.test.resources and named SearchPanel.properties:

userSearchButton. label=Search for User

userSearchButton.font=Arial-BOLD-24

userSearchButton.foreground=0,0,255

Once you launch the application, keying off of the setName call, your properties from the SearchPanel.properties file will be bounded to the searchButton defined in the SearchPanel class. Slick hu?

To set tooltips, actions and other properties, that is all doable using annotations and the resource files as well. I’d suggest taking a look at Dean’s tutorial to see how that works in the context of an entire application.