Hans Muller released the first prototype implementation of JSR 296, Swing Application Framework. JSR 296 promises to simplify the development of rich-client applications by providing functionality that encapsulates Swing best practices.
JSR 296, Swing Application Framework, spec lead Hans Muller released the long-anticipated first prototype of what will become a standard framework for constructing rich-client Swing applications.
In an interview with Artima, Muller noted the difference between having a UI toolkit API, such as Swing, and a more specialized framework targeted at desktop application development:
Generally speaking, application developers need a process to follow for analyzing their own requirements and creating an implementation design. They also need API support for essential application parts—resources, actions, tasks, sessions—and support for putting those parts together in IDEs.
Most experienced Swing developers have sorted these issues out for themselves, and many of them are justifiably proud of their own skills. Novice Swing developers, however, find the lack of guidance and support in these areas intimidating or frustrating.
What we're trying to do in JSR 296 is to move desktop application construction from the realm of artisans and specialists to straight ahead engineering. If we're successful, more high quality Swing applications will be built by developers with less experience and less frustration than ever before.
In releasing the first JSR 296 prototype, Muller commented that:
The intended audience for this snapshot is experienced Swing developers with a moderately high tolerance for pain. Although JSR-296's ultimate goal is to bridge the gap to novice developers, the project's current doc/spec/robustness qualities aren't a good match for novices just yet.
So we're looking for feedback at this point... We're not looking to adopt an existing framework or even for code contributions however if there's an existing Swing application framework you're fond of, then feedback of the form: "framework X has a feature that JSR-296 lacks and the reason X is important is ...", would be great. Reports about bugs in the current implementation would be welcomed too.
If building and deploying Swing applications became as easy as building browser-based applications, would that make you more likely to choose Swing as a UI for your projects?