Home

JSR-296: The End of the JFrame?

Submitted by Geertjan Wielenga on Tue, 2008/03/18 - 11:27am
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Technorati
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"); 
        frame.getContentPane().add(label); 
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
        frame.pack(); 
        frame.setVisible(true); 
    } 
}

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");
        show(label);
    }
    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?

 

0
Average: 3 (2 votes)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

cfagan replied on Tue, 2008/03/18 - 12:32pm

I did a few small apps with JSR-296 early in it's existence. I have to say that it's really refreshing to have a defined application structure. I plan on using it whenever possible. My only concern about it is if/when we get some form of closures the @Action annotation might become deprecated rather quickly. Maybe there is room for both?

Patrick Gotthardt replied on Tue, 2008/03/18 - 3:26pm in response to: cfagan

Well, let's hope @Action gets deprecated as soon as possible. It's a nice solution for quick-and-dirty programming but for anything with substance, it isn't an option. Just think about it: You're selecting actions based on Strings (based on the name of the method with the @Action-annotation). Not just within a component where there typically is a nice little ActionMap, but throughout your code. That's bound to break sometime.

It also reduces the opportunity for code reuse.

This should've/could've been a framework embracing good practices for developing Swing applications, instead we have something as short-sightened as this.

Geertjan Wielenga replied on Tue, 2008/03/18 - 3:38pm

I suspect that the best parts of this framework will outlast the worst parts. To me it seems that SingleFrameApplication should end up replacing JFrame, while the @Action annotation might have a shorter shelf life.

Johnny replied on Wed, 2008/03/19 - 12:52am

Do we need another framework? No, thanks.
This seems like totally unnecessary changes - if people want something like this, it is very easy to implement it yourself.
If something like this is indeed going to be implemented, I pray I won't have to see it as part of the "core classes", but rather as an option that is not required, i.e. that I won't have to install.

Karsten Lentzsch replied on Wed, 2008/03/19 - 2:58am

First off, I like the JSR 296. I have seen that it helps developers organize their Swing production process, and in turn reduces the time necessary to do everyday Swing work.

This JSR has not reached the "Early Draft Review" and we experts in the 296 expert group have not discussed and decided what will be its prelimineray or final scope. The frame setup feature, and more generally the view support, are not part of the 5 issues the JSR shall focus on. As an expert in the EG I will argument and vote against the inclusion of current view support in the spec.

A view structure, l&f choice, and UI configuration may change with new user experience paradigms. And only stable parts shall make it into the spec. Useful default configurations shall be moved to default Application implementations; they may ship with the 296 reference implementation. My implementation of the JSR 296 keeps the view part out of the core, and the views defined by my standard Application subclass significantly differs from the view setup done by Hans' code.

Richard Osbaldeston replied on Wed, 2008/03/19 - 6:05am

Would like an update on what's happening with JSR296 and JSR295 - to us outside of Sun it looks like development has been shelved on both in favor of JavaFX. The lead devs aren't even around to offer support in their forums? Know Hans is working on scenegraph, but haven't heard anything from Shannon in an age.

Also hoping that once the closures and properties issues have been decided they won't both suddenly leap to JDK7 only overnight (still using 1.5 which is unlikely to change for some years yet because of our customers hardware & support contracts).

I've had issues with AppFramework when I tried to use it. I wanted a DocumentModel app where I'd have multiple top-level frames (not secondary). The ApplicationContext/ActionManager being singletons really makes life difficult in terms of reusing classes in other application instances. The use of static factories in the Application code also made it openly hostile to per-instance type changes. The ResourceManagent also starting getting on my nerves as I had to repeat keys and values multiple times and I couldn't quite get my head around when to use the appframework resources and when to mix with normal resourcebundles. As some of our objects are shared between layers (dont want swing/appframework classes polluting the server code). I too find @Action embedding actions into the view code distateful. Much like the Java tutorials and Netbeans Matiesse encourage developers to extend JComponents rather than 'use' them ref: The Imperial Rules.

Anthony Goubard replied on Wed, 2008/03/19 - 12:56pm

I've used the Swing app framework for one of my application and I'm not sure the SingleFrameApplication class is the correct approach. In my case I just wanted to write an application. Then I want this application to run in a JFrame and in an Applet. I would prefer to have an Application class where you only have to provide the RootPane and the menu and the framework will take care to provide you the JFrame or Applet you need to show you application. This way could plug your panel in a NetBeans dock or as a widget. Note that there would still other things to take care of as for example in Applet you're in a security sandbox.

Richard Osbaldeston replied on Thu, 2008/03/20 - 4:56am in response to: ag13098

Anthony isn't Applet support why Views were being introduced? Although I don't think it's been fully implemented yet (given the comment in the code about Views being experimental).

Also I was a bit slow checking my mailing lists (well theres been no news for ages). Hans has been asking for developers to help support and move forward Appframework JSR296 see: https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1445

Wonder if bensbindings might not admit to the same problem? Swing team spread too thin?

Carl Antaki replied on Thu, 2008/03/20 - 12:05pm

It's great I just have used it in a small project I'm doing. Instead of writing all the boilerplate code to save Window positions and have an unstructured code, the Swing app framework makes code more readable and more maintainable as resources are stored in .properties files and no extra code is required, the annotation mechanism is very powerful too. I hadn't explored all the features, I will definitely use it for any small or mid size Swing project.

Jeroen Wenting replied on Tue, 2008/03/25 - 6:10am

So, 6 lines of code to use a JFrame are replaced with 7 lines of code in JSR-296 and that's supposed to make things shorter?

Geertjan Wielenga replied on Tue, 2008/03/25 - 6:17am

The shortness is not the point. The point is that you get persistence of the frame across restarts without any coding. In other words, start up the app again, and the last position and size of the frame are retained. That doesn't happen with JFrames, does it? For JFrames, position and size return to their defaults.

Patrick Gotthardt replied on Tue, 2008/03/25 - 11:18am in response to: jwenting

And while we're still stuck with counting things: Obviously Geertjan included all Swing developers most favorite error (by decision, I take it ;) ): He constructs the frame on the main thread, instead of the EDT. So add another 3 lines of code to his sample and we can actually notice a decreased line count and an increased feature count (as Geertjan explained).

Now that sounds much better, doesn't it? 

Michael Bushe replied on Wed, 2008/10/29 - 8:23pm

Karsten - is there a specification document for 296?  Is it public? All I've seen is code snapshots and some small writeups.  I'm not sure how you can have "your" implementation of the standard without a specification to work against. 

Perhaps the best way to communicate that 296 is not dead is to, in the spirit of the JCP, make the process more transparent.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.