Over a million developers have joined DZone.
Platinum Partner

JSR-296: The End of the JFrame?

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

I've been quite sceptical about the usefulness of JSR-296, that is, the JSR for the Swing Application Framework. Last week I had the opportunity to present a few demos around it, at Sun Tech Days in Johannesburg, South Africa. During research on this topic, I became very impressed by it. Here I explain why... and invite you to share your thoughts.

First off, let's quickly recap what JSR-296 wants to do for us. Simply put, it focuses on 5, and only 5, very specific services for Java Swing—lifecycle support, resources, actions, tasks, and session state. A very clear and visceral example of the place that JSR-296 seeks to fill can be illustrated by two very small code snippets. Here's your typical common-or-garden JFrame:

import javax.swing.JFrame;
import javax.swing.JLabel;

public class HelloWorldSwing {
public static void main(String[] args) {
JFrame frame = new JFrame("HelloWorldSwing");
final JLabel label = new JLabel("Hello World");

Lots of code in there. The only reason why none of it is surprising is that all of it is so standardized at this point. But ask yourself why you need those last three lines. Why do you need to specify exit on close? Why do you need that pack statement? Why do you need to specify that you want the JFrame to be visible? Aren't all of those things obvious?

Here's how you would do the same thing, via JSR-296:

import javax.swing.JLabel;
import org.jdesktop.application.Application;
import org.jdesktop.application.SingleFrameApplication;

public class MyApp extends SingleFrameApplication {

@Override protected void startup() {
JLabel label = new JLabel("Hello World");
public static void main(String[] args) {
Application.launch(MyApp.class, args);

Now that makes a lot more sense. Only the code you're actually interested in is the code that you're providing. On top of that, there's a rather big bonus—the state of the frame is persisted across restarts. What does that mean? When the user starts the application, moves it and/or resizes it, the new position and size are automatically retained when the application is started up next time. No coding on your part. That's the point of JSR-296 being a framework—it takes care of infrastructural concerns for you.

Hence, that's two services taken care of—lifecycle management and session state. The next thing I was really happy about was the service that provides Tasks. In the context where I was using it—NetBeans IDE—this worked brilliantly. You can use the IDE to convert a method to a background task so that methods that would otherwise take up a lot of time and block your user interface can run asynchronously in the background. But all of the coding in this area is taken care of by the IDE. Without a single line of coding on your part, you have an asynchronous task, with very clear methods to override for specifying what happens during the task and what happens upon success or failure.

The services providing actions and resources are two areas that I've not looked at too closely yet. This is largely because the IDE handled these areas for me seamlessly. However, so far I am extremely impressed with the simplicity of the framework and its lack of ambition. In other words, I'm glad it's not trying to do more than it's currently doing. Its strength lies in its simplicity.

As far as I'm concerned, there's no need to ever create JFrames again. (Although existing JFrames can be hooked into the Swing Application Framework, which is also a strong advantage.) So, what's your take? JSR-296: a good thing? Or not?


The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}