Looking at JSR 296 I have the impression that it should focus on data-centric applications and that the target audience should be the newcomer rather than the programming expert.

JSR 296 is a specification request for a Java framework supporting rich client development with Swing. It is discussed, for instance, here and here.

If it’s possible to really simplify development with Swing, e.g having developers not worry about all those threading issues, hiding the complexity of MVC programming (at least for beginners), more people would be attracted to Java.

Let them easily access databases, provide decent data binding & validation, provide forms communication support, provide application state handling, provide launching support, action management support (menus, toolbars and popups). Personally, I’d like to assume that the data, which is manipulated by and large, are Java Beans and collections thereof. Therefore a set of enhanced, easy-to-use JLists, JTables and JTrees should be part of the reference implementation. Oh, and let’s not forget to make it pretty by default. (Some of the points I made have been already mentioned in the discussions I referred to above.)

In addition to the technological questions, the target audience of the reference implementation should be the sole developer, or very small team, that needs to handle everything from database access, business logic development, functional development, design & layout, up to versioning and deployment. I think it’s also necessary to assume little or medium knowledge of Java development, say people who have worked with VB6, that are now being kicked away by Microsoft. All in all, the JSR 296 implementation should provide a Simple-Swing-JDBC-FormsLayout-Java platform. (Well, we could argue about the layout manager. For myself, a combination of FormsLayout, BorderLayout and BoxLayout has worked very well thus far.)

When individuals are enabled to quickly whip together stable (and pretty) solutions to problems in an existing day-to-day enterprise infrastructure (meaning their company), the platform, that they do this with, gains momentum.

At the moment I would consider a set of loosely coupled components that wrap Swing, JDBC, etc. as they are, plus a recommended process how to use these components to be the best alternative to achieve all this. Sure, a thorough discussion of the pros and cons will reveal more aspects that I am not aware of. Implementing JSR 296 is by no means a simple task. I tip my hat to the people doing it. But the direction Java is taking with this is a good one and I am hopeful of the outcome.