John O'Conner's Blog

A Simple Framework for Desktop Applications

Designing desktop applications can be tricky. Threading, resource management, launching, shut down...there are a lot of things to think about. Nothing akin to rocket science, but lots of things can go wrong, and do. A desktop framework would bring much needed consistency to the task, providing structure and encouraging adoption of best practices for application design.

At the JavaOne conference last week, the dynamic desktop duo Hans Muller and Scott Violet presented their plans and ideas for a simple framework for desktop applications. Their presentaion focused on possible APIs, but they acknowledged that tools (like NetBeans) would be important for a successful framework.

They gave some examples of common bad practices that demonstrate why you might want a little guidance (a framework):

• your app runs on the main thread
• your app IS-A JFrame
• your app can only support English
• your app is a tangle of actionPerformed methods that block the event dispatch thread (EDT)

Goals for the framework include these:

• must be as small and simple as possible, but not any more
• must be able to describe it within an hour
• work very well for small and medium sized apps
• avoid scripting languages, GUI definition schemas, etc that lock you into any tool.

The framework isn't available yet, but JSR 296 defines the request for the framework. You should expect to see a java.net project for it in the near future. If all goes well, Hans and Scott would like to see this minimalist framework in Java SE 7 (Dolphin).

A framework in the core libraries? Although I like the idea of some guidelines, even a java.net project to assist desktop application developers, I'm not immediately sold on any argument to include it in the actual JRE. Hey, but I don't have any say in these things....or do I? Do you?

As luck would have it, Sun's last general session at JavaOne stressed the need for community involvement in the Java platform's innovation. You have an open invitation to join the Java Community Process, comment on proposals, submit some of your own work. So, yes, you do have a say in such things, but you have to register too.

Comments

• 
  Thanks John for this summary - i was really looking forward to getting some more details on what JSR296 is about :)

  This is great initiative and I'm gonna sign up to the JCP today and get involved :)

  The issue of event handlers and EDT is a big one for me. My last project I got in such a tangle with SwingWorkers upon SwingWorkers, and the code became increasing difficult to follow! I will blog on what I ended up doing which worked in that case, but is by no means a "solution to all problems."

  I've ended up rolling my own framework many times, for each new client/project, which is crazy! So we really do need a standard Swing framework. I blogged on this inter alia in "Swing trumps Ajax".

  I thought that JDNC was aiming to become the "standard framework" tho? I'm interested how JDNC and JSR296 (and JSR295, on bean binding) fit together? I guess JDNC are components that would fit into this framework, which serves as plumbing for components.

  By the way, I've drafted a blog article on bean binding for GUIs, called "Beans Roti (Chapter 1)" which I will publish later on my blog .

  In subsequent chapters to that, I'll present some solutions I've tried in Swing application frameworks for clients, which are making their way into my project aptframework.dev.java.net which hopefully will become JSR296 compliant in future! :)
  

  Posted by: evanx on May 24, 2006 at 02:18 AM

• evanx: JSR296 will most likely be implemented in a public open source subproject of SwingLabs, just like JSR 295 will be. What was JDNC has been split out into SwingX and several other sub projects of Swinglabs as part of a general refactoring, about a year ago.

  Richard

  Posted by: rbair on May 24, 2006 at 08:05 AM

• John: Personally I see this as a much needed addition.

  I understand your reservations with regards to Scott & Han's take on adding it as core; however, I think the one plus is that if it's available as a framework one can **choose** to use it if one so desires.

  It would, as you say, help promote best practices which so often are sorely lacking. Obviously, in the absence of such, it tends to expose poorly designed desktop apps that, in turn, only aid in perpetuating the perception of Java as a poor choice on the desktop side.

  I've had a discussion on this topic with Ben Galbraith and had the opportunity to look into some of his efforts in this area. It's an area I know he's given a fair bit of thought to and I know know has an opinion on :) ... I think he'd be a good addition to the JSR...hopefully we'll see him sign up as well.

  As evanx mentioned...I'm also curious as to the what he states as "bean binding for GUIs". The sticky wicket is going to be a generalized enough framework that still offers robust enough functionality to make it legitimately useful. This balance will obviously be the key I think to it's adoption as a feasible framework.

  ~Todd
  

  Posted by: viegs on May 24, 2006 at 12:08 PM

• There are a lot of things that can be provided to facilitate application development that can be used independently. Several such things:

  Population of action values from a single resource key (name, accelerator, mnemonic, icon, tooltip, etc).
  Delegation of menu items to actions in the current context (I'm writing a blog entry on this one.).
  About box
  Splash screen
  Several well-implemented, well-documented design patterns to avoid direct invocation of program logic in "actionPerformed"

  None of these items depends on anything else, but would go a long way to facilitating app development without tying someone to the whole bundle.

  Posted by: twalljava on May 24, 2006 at 01:33 PM

This work is licensed under a Creative Commons License.