Interview with Hans Muller about JSR-296: Swing Application Framework
Artima has an interview with Hans Muller, the spec lead for JSR 296: Swing Application Framework discussing where it fits in with existing gui toolkits and rich client platforms as well as how it addresses the main developer frustrations of desktop Swing development, including wiring actions, multithreading, and GUI design.
JSR-296 aims to simplify Swing development by providing a small set of support classes to make getting started with a Swing application a lot easier. When the JSR was announced, there were fears that Sun was going to throw the Netbeans RCP into the JDK, but this is not at all their intention. Hans describes how JSR 296 fits between GUI toolkits and rich client platforms:
The JSR 296 project differs most from SwingLabs in that the JSR's scope doesn't include new Swing components. However, the framework does include explicit support for actions and tasks, multi-threading and those topics have been investigated by the SwingLabs community as well. The NetBeans platform (NBP) is much closer to the spirit of JSR 296, in the sense that it's also a framework within which one can build applications. However, the NetBeans platform is much broader in scope: In addition to addressing many of the issues that are fundamental to JSR 296, it defines a module system, a docking window system, and a very flexible persistence layer that resembles a file system. An overall goal for JSR 296 is to make it easy for new Java developers to get a solid Swing application up and running. A corollary is that the API we define has to be modest in size and easy to learn.
Hans lists the biggest problems that the JSR is trying to solve as:
- Now What? - How do you get started with a desktop app beyond the main method?
- Wiring Actions - Using a new @Action annotation to facilitate the creation and use of Action objects.
- Multithreading - Expanding on SwingWorker with two new classes: Task and TaskService
- GUI Design - Improving resource management by standardizing where ResourceBundles are stored and providing for resource injection and type conversion.
Hans and Scott Violet presented some, prototype work on this at JavaOne.
InfoQ covered the announcement of the spec in May
As they say, I guess it is better late than never.
I just hope two things: 1) that it is a real framework in the technical sense (of inversion of control), and 2) that it is half as good as the Cocoa framework(s) (from Apple for MacOSX) that I believe still sets the Gold Standard for desktop application frameworks (although of course it is not implemented in Java, although it did have a Java API).
PS Of course, this is supposed to be encouragement for Hans and the JSR-296 team, not a criticism. I think there success is crucial for the success of desktop Java.