Malcolm Davis's Blog

JavaOne Blog 4: JSR 296 Swing Application Framework, nice but lacking.

The JSR claims to be a canonical form a Swing application, but I don't think the JSR team has used many applications.

Let's start with the basics, where has this JSR been hiding out? Eclipse Rich Client Program (RCP) has had many of these features for years, and more.

The application JSR includes things that are part of a 'typical' application such as (life-cycle, resource, action, task and session state).

Most notable similarity to RCP is the life-cycle. The life-cycle allows the insertion of code during specific points in the application life-cycle such as: launch, initialize, startup, ready shutdown, exit. For instance, if you need to handle something prior to application closure, just override the shutdown() method.

However, there are many features that are used and constantly re-developed, that need to be included in the JSR to create a truely canonical application framework. This features include:

Help: Mapping controls like screens, buttons and input fields to Help documentation may seem OLD School, but it is the one item that I get pinged on when it does not show up in an application. This is something that is part of Eclipse RCP.

Preference screen: Looking at NetBeans, preference screens are not a hot topic. However, Preference screen design and navigation is one of the really cool features of Eclipse and RCP. Preference screens are part of almost every application I use, and is generally on the list of requests that come from my users. A mechanism to simple save and uses Preferences would be useful.

Update: How should an automatic update mechanism work? This is always a problem for every application. Find, download, and install updates are an issue with the conical application.

The primary issue is what distinguishes the differences between a 'canonical' application and an 'environment' such as NetBeans. Help, Preference and Update are part of my vision of a canonical application.

Special Note: The the high point of the JSR is Task. Task design and implementation is very cool. Task will help people that struggle with the SwingWorker. I also think the Task service will help cleanup code.

Comments

• As JSR 296 doesn't really help building cone-shaped objects, I assume you mean "canonical" and not "conical"?

  Posted by: pseudonymorama on May 09, 2007 at 02:12 PM

• Malcom--there is an open-to-all and active discussion/mailing list for the JSR. The expert group is not only listening, but also incorporating changes people suggest. If you have features you'd like to see, please join the mailing list and contribute. This is especially true if the JSR will not serve your needs as-is, I'm sure they'd want to know why. It would be sad if the feedback got lost on your blog with all the J1 news out there. Regards, Patrick

  Posted by: pdoubleya on May 09, 2007 at 10:14 PM

• @pdoubleya - yes, but whinging about it publicly is more fun than contributing :-)

  Posted by: goron on May 09, 2007 at 10:49 PM

• I think you've missed the point of the application framework. It does not aim to compete with heavyweight RCP (Rich Client Platforms), such as those available from Eclipse, Netbeans, or Spring. It aims to fill the gap between these heavyweight solutions and "from scratch" solutions where every UI container and component are coded by hand, by automating fundamental tasks.

  I think as such it's very useful, because I tend to find myself writing a mixture of big applications and small applications. For the big applications, you can turn to the RCP platforms (although often I avoid that, because they impose too much of a rigid structure which aren't always a best-fit for the application, a bit like programming in a straitjacket...), and for the small applications, there's a lot of boilerplate code involved in creating windows, actions, tasks, and localization: this is where the application framework steps in, and furthermore helps beginners get started without worrying too much about things like the event dispatch thread.

  - Chris

  Posted by: chris_e_brown on May 10, 2007 at 01:04 AM

• Miss the point?
  If this is suppose to be a lightweight structure, why add something like remembering session state? Why add yet another way of handing resources? Why not name it something else and make the Task service more in the developers face?
  ?The application framework is something between an OSGi solution and the simple Swing app? Ack. Pollute the API, make the developer wonder what they are suppose to use and do, accidentally mix different techniques. The whole thing is a recipe for disaster.

  Posted by: malcolmdavis on May 10, 2007 at 08:26 AM

• You are right: it's pollution of the API. With the announcement of JavaFX, I don't see the future of Swing application framework. We will need another framework to support JavaFX.

  Posted by: smsajid on May 10, 2007 at 09:40 AM

• Help: Maybe, leaning to no. I myself have never written an application with help, I always direct to wiki page. Simple apps don't need it. This could be core, but I'd err on leaving it out.

  Preferences screen: No. Not every application needs one. It's not essential for apps with only a few simple preferences which are better served by menu options. A preference screen is definitely not core.

  Update: Java Web Start. If you have problems with it, then Sun should focus its effort there.

  Storing session state: Absolutely core. Every single app I've ever written has needed it, and even small prototype apps can benefit from storing simple window geometry. Core. And don't mention the Preferences API; I'd rather use AWT than a Swing app with the Preferences API.

  Resources: I'd maybe agree with you here. But it's hardly a big deal should you decide not to use them. My apps can not easily be retrofitted to use it, so I'll probably just not use it.

  And regarding the lightweight comment. I'd say 180kB is fairly lightweight compared to any RCP platform out there.

  Posted by: brendonm on May 10, 2007 at 10:29 AM

• Storing session state? Does NetBeans recall session state, opening the correct windows, bringing up the files, navigating the tree back to where the user left off?
  Recalling the absolute position and location of a window is ok, but minor
  Update via Java Web Start?   I've always thought of Web Start as something for deploying web applications. That to the side, I personally do not want the user to have to download and reinstall an application each time there is an update. I want it to be transparent to the user.
  I guess I am having an issue with something between simple Swing and sophisticated commercial application. Instead of 2 choices, the developer has 3. Why not take the lessons learned from RCP and NetBeans, and generalize the problem space? A poor mans OSGi.

  Posted by: malcolmdavis on May 10, 2007 at 10:56 AM

• re: missing the point and session state... one of the basic things a user expects from an application is that it remembers things like window size and position, column widths in tables, and stuff like that. It's not like they're implementing a database here...!
  - Chris

  Posted by: chris_e_brown on May 10, 2007 at 02:38 PM

This work is licensed under a Creative Commons License.