Swing and JDK 7
By dannycoward on Feb 04, 2009
Prompted by a vigorous discussion on Jonathan Giles blog about whether Sun is ready to do a 'Swing 2.0', its time to lay out where we (at Sun) are with Swing. So here it is.
Swing and Sun
Swing is really important to Sun. We have a large and vibrant group of developers who are developing and maintaining Swing GUI applications. Its APIs, components and underpinnings are critical to Java's future position in developing rich client applications of all kinds.
In contrast to the early years of hectic build out of Swing, we've slowed the growth of APIs over the last few years. This is largely because, despite gaps in the API set for some applications, compared with those early days (or with JavaFX today), the Swing APIs are broad enough to build most enterprise desktop applications. And that which is not there can most often be added with a third party library or component.
Building with Swing. Building on Swing
At the same time we've also seen a growing role for Swing, and its underlying graphics runtime, as a basis or inspiration for other RIA technologies. Such as our own JavaFX, which uses both graphics stack and many of the Swing components in its desktop profile, or such as Griffon, Thinlet, Pivot and LWUIT to name but a few.
So our focus has been shifting (starting well before the advent of JavaFX, even of Java SE 6) from filling out what were then major gaps in Swing as a UI toolkit, to making it easier to develop with Swing, and to making the runtime deploy and perform better. Progress on both counts are a benefit to Swing developers but also to other technologies that depend on Swing and its foundation.
Sun's priorities for Swing and JDK 7
To that end, the priorities for our effort between JDK 6 and JDK 7 are: first to make the runtime lighterweight (faster download, faster startup), better integrated into the browser, and with improved runtime performance. Some of this we have already delivered in Java SE 6u10, but there is more to come. And second to take a big swing (!) at reducing the amount of boilerplate code and conceptual complexity in a developing typical swing application with the Swing Application Framework in JDK 7.
We've also set things up in OpenJDK to make it easier for developers outside Sun to contribute to Swing, and we hope to help integrate some backwards compatible features created outside Sun into the JDK. We'll be working with the XRender pipline team to bring graphics acceleration to Java on Unix platforms. Also in JDK 7 we'd like to include other components such as JXLayer, the DatePicker, and CSS styling also. And perhaps other components or features, as mentioned in some of the comments in the thread, all such contributions depending on the usual constraints of quality of implementation, accompanying tests and of course, timing.
On a related note, some have mentioned a desire to use JavaFX features from Swing: we're interested in hearing what kind of Swing applications you are writing that might require JavaFX components to be embedded as we figure out the next releases.
Not ready for an incompatible revolution
Now, some of the discussion at Jonathan's blog reminded us of the many areas in the APIs that need updating: largely because of the advent of new Java language features and SE APIs that were added after the Swing APIs were created, that now provide much more convenient and reliable ways to manipulate Swing than were possible before. But we have a more conservative attitude towards breaking backwards compatibility than some of the commenters on the thread (and beyond): an attitude formed out of years of talking with developers and customers who depend on Swing. (As an aside, you may be curious as to the inherent design issues regarding the EDT). Now JDK 7 modularity will likely provide a neater way to move gracefully to some possible future backwards-incompatible version of the Swing APIs. But in terms of where we put our effort today, we don't think such an evolutionary cleanup, albeit useful and desirable, its enough reason to disrupt existing applications, tools, books, tutorials, courses and frameworks that are built with today's Swing.
Are you ?
But if what you want is revolution not evolution, if you would like to see bigger, more radical changes inside Swing, then please consider that you have all the source code for Swing together with the supporting infrastructure to create a project and broadcast its existence at OpenJDK.org.
It's why, in part, we set up OpenJDK: to make it easier for you to bring the next big RIA idea to life.