Swing Application Framework (JSR-296): new concepts, new features

Swing is a widget toolkit for Java. It is part of Sun Microsystems’ Java Foundation Classes (JFC) — an API for providing a graphical user interface (GUI) for Java programs.

Swing was developed to provide a more sophisticated set of GUI components than the earlier Abstract Window Toolkit. Swing provides a native look and feel that emulates the look and feel of several platforms, and also supports a pluggable look and feel that allows applications to have a look and feel unrelated to the underlying platform.

Framework Architecture

Two classes help you manage your application: ApplicationContext and Application. The Application and ApplicationContext objects have a one-to-one relationship.

The ApplicationContext provides services to the application as shown in Figure 1.

Figure 1. An ApplicationContext provides services to your Application instance.

Those services include the following:

• Localizable resource management
• Task services and monitoring
• Event-action management
• Session-state storage

All Swing Application Framework applications must subclass either the Application class or its SingleFrameApplication subclass. The Application class provides lifecycle methods for launching the application, starting the user interface (UI), and shutting down.

The SingleFrameApplication adds a default main GUI frame, retrieves and injects default resources, and uses the ApplicationContext to save and restore simple session state. Session state includes UI component location, size, and configuration.

Both superclasses provide an ApplicationContext, but the SingleFrameApplication class provides additional default behaviors that use the context. You probably will not use Application as your superclass. Most likely, the SingleFrameApplication class provides the default behavior you need. In the future, other subclasses should be available to handle multiframe applications as well. Regardless of the superclass, your application will use its ApplicationContext instance to access most services that the framework provides.

Application Life Cycle

All applications have a life cycle of events that are called in a specific order. Your primary Application or SingleFrameApplication subclass should start in its static main method and should launch the application from that point. The supported life cycle includes the following methods, called in this order:

1. launch — You must call this framework method.
2. initialize — The framework will invoke this optional overridden method.
3. startup — The framework will invoke this overridden method.
4. ready — The framework will invoke this optional overridden method.
5. exit — You must call this framework method.
6. shutdown — The framework will invoke this optional overridden method.

Your application’s minimum requirement is to call the launch method and to override the startup method. By calling the launch method, your application begins the life cycle. The launch method will then call the initialize, startup, and ready methods. You should also handle your application frame’s closing by calling the exit method, which will eventually call the shutdown method. A few examples should help make the sequence more clear.

Swing Application Framework update (Alexander Potochkin’s Blog)

As you probably know, a few weeks ago I became the new specification lead for the Swing Application Framework project (JSR-296). This project has been fairly silent for the last little while, so it is high time to continue with working on this framework and complete it timely. The main goal of this project is quite ambitious: create a Swing framework which allows to quickly create a simple Swing application and which is also flexible and extensible for the big commercial applications. The key to success it to recognize the common patterns and the best practices that help to create a good Swing application and implement them in the Swing Application Framework.

In this blog entry I want to describe the recent changes and give the reasons why it was done this way and bring up some issues to think over. Don’t hesitate to share your opinion, we make it for you and your feedback is very important for us. The project is now in transition state and the API may be changed. The latest source files you can find in the Subversion reporsitory, zipped files are also available, the previous stable version can be found here.

One frame application

The framework is to be friendly to beginners and creating an application with a single frame should be very easy. Remember the time when you were writing your first Swing application – JFrame with a main component, toolBar, statusBar and menu what questions did you have?

Here is my list:

• How to create a JFrame?
• How to place components properly to the frame?
• How to show the frame?

Let me show you how it can done with the latest SAF:

public class SingleFrameExample2 extends SingleFrameApplication {
    @Override
    protected Component createMainComponent() {
        JLabel label = new JLabel("JLabel");
        label.setFont(new Font("LucidaSans", Font.PLAIN, 32));
        return label;
    }

    @Override
    protected JMenuBar createJMenuBar() {
        JMenuBar bar = new JMenuBar();
        JMenu menu = new JMenu("JMenu");
        menu.add(new JMenuItem("JMenuItem"));
        menu.add(new JMenuItem("JMenuItem"));
        bar.add(menu);
        return bar;
    }

    @Override
    protected JToolBar createJToolBar() {
        JToolBar toolBar = new JToolBar();
        toolBar.add(new JButton("JButton"));
        return toolBar;
    }

    public static void main(String[] args) {
        launch(SingleFrameExample2.class, args);
    }
}

By running this small example you’ll see the frame with the menu, toolbar and the label as the main component. This frame will have the size sufficient to all its subcomponent and be shown at the center of the screen.

Open issues

With the provided test case you can easily create one frame, but what about more realistic multi frame applications? The SingleFrameApplication creates the main frame and exits when the frame is closed. It may be not the case if there are more frames in your application, for example you may want your application to stay open until it has at least one frame visible. It is also important for the modern application to save the state of a frame (like its size and position) when it is closed and restore it when the application is started again.

All that mean that we can’t just create a frame or dialog and show it. We need a way to let the application set it up and add closing listeners or set the frame’s bounds. The current SingleFrameApplication has the

public void configureWindow(Window root, Object key)

which should be called after you create any secondary window in your application. The first parameter is the window itself and the second one is the identifier of this window, which is used to save the window’s state.

This design is not very flexible, for example it is difficult to set which window should close the application

Proposed API

Introduce a new method in the Application class

public void registerWindow(Window w, WindowContext c)

and add a new WindowContext class which will keep the identifier, know how to configure this window and whether window’s listener should close the application when this window is closed

abstract public class WindowContext {

    abstract public Object getIdentifier();

    public void configure(Window w){
    }

    //Is it a good name for this method?
    public boolean isClosingApplication() {
        return false;
    }
}

(more)

Swing Intro

[wikipedia.org]
[http://weblogs.java.net/blog/alexfromsun]
[http://java.sun.com/developer]