Swing 2.0 - Where to from here?

So, Danny Coward has replied on behalf of Sun on the feasibility of Swing 2.0 - a backwards incompatible change to Swing. His basic statement was that backwards incompatibility is not an option in the near or medium term, but perhaps in the long term. Perhaps the major oversight in his blog post was that there has not yet been any suggestion that Swing 2.0 replace Swing 1.0 - it could be that a Swing 2.0 develops alongside the more stable Swing 1.0 branch. Through the use of differrent package names, and with the advent of Java 7 and improved modularity, Swing 1.0 can stay as-is, allowing for all existing Swing applications to continue to work. Therefore, there is no need for Swing to move from its current course.

My argument is that a Swing 2.0 brings with it reinvigorated development and a pre-release mentality to perfecting APIs, instead of simply maintaining them. Given the current state of cross-platform desktop GUI API's, I still think Swing has a great chance of being hugely popular for the foreseeable future.

The problem is that Swing is not the primary focus for Sun anymore, which is now JavaFX. Swing will only be allow to prosper and grow if there are direct benefits for JavaFX. Whilst this is better than nothing, it means that some of the main deficiencies in Swing are being ignored. Our suggestion for Sun to consider developing a Swing 2.0 is unattractive as JavaFX is not an immediate benefactor. Perhaps the biggest hurdle for both sides of this discussion is one of inertia - to move people onto Swing 2.0 does nothing to appease the marketing side of Sun, who are shouting from the rooftops 'JavaFX, JavaFX, JavaFX'. At the same time, we Swing developers are not keen on moving over to JavaFX, as it is not what we are used to, what we are skilled at, or ready for developing the kind of applications we need to develop. This leads to trouble - Swing 2.0 can not be seriously considered within Sun, as there is little return on investment, and at the same time it gives Swing developers time to pause and survey the GUI API landscape, to see where to reskill.

To be fair, Swing is an excellent toolkit, but it is dated and needs a refresh to keep it current. I fear that with the focus on JavaFX and RIA, there is no one at Sun really interested in Swing for the sake of desktop applications - the kind that used to be thought of before RIA was all the rage. In my personal circumstances, I primarily develop client/server applications, where the client is deployed in enterprises and must look like a 'proper' application, otherwise people worry. This extends to using any look and feel other than the desktop default (sorry Kirill!). Therefore, whilst I know I'm not cool to be developing desktop applications using Swing, I know my skills are relevant, as I am kept busy developing Swing-based applications. (I'm used to not feeling cool - I don't do AJAX, and I don't do RIA :-) ).

The onus has been put back on the community to develop their own solution. Perhaps one day this may be part of the JDK, perhaps it won't. There are various projects, a number of which were discussed in my first Swing 2.0 post, that could be part of Swing 2.0. Projects (and their owners) such as Swing-Generics, SwingX, MigLayout, JGoodies Beans and Validation, FEST, all have valuable opinions with respect to their areas of expertise, and a Swing 2.0 would not be even considered were it not for these projects.

I want to refine the previous discussion. Please, regardless of whether you agree or disagree, reply to this post, but try to keep it focussed on this one aspect: Is Swing 2.0 about undertaking a major refactoring of Swing 1.0, or is it about starting with a blank slate? Let me put forward my preferred approach: I would rather take the current Swing codebase and begin a major refactoring. In my opinion, it is quicker (to get started and to see results), and perhaps easier.

In addition, if you are interested in being involved, let me know, either by commenting on this blog or by emailing me privately. To be clear though, even now, I am not suggesting we start a Swing 2.0 project, and even if we did, it can't be a free-for-all with everyone working on it - the end result will be no better than the currrent Swing, and would in all likelihood be worse. We need an API driven by use cases and designed with very careful consideration. I do not want to rush into a Swing 2.0 without giving huge consideration to every voice out there. Regardless of whether the suggestions are part of a Swing 2.0 spec, we must consider them. Only then may we design a Swing 2.0 that we would prefer to use over Swing 1.0.

Cheers!