The way forward for Swing, SwingX, and JavaFX

Chances are that many readers of the front page / editor's blog were following along last month as Kirill Grouchnikov argued that the de-funding of SwingX implied that Swing was now at a dead end, and said the handling of SwingX (and its painters feature in particular) destroyed developers' trust. It kicked off a lot of discussion, and a particular angst: that the demands of JavaFX were completely draining resources from every other Desktop Java project.

With JavaFX now released, Kirill has taken his questions to the source. In Java on the Desktop, the past, the present and the future - interview with Richard Bair, Richard Bair answers Kirill's questions on Swing, SwingX, JavaFX and Java on the desktop in general, while saving some of the announcements for the next week's Devoxx conference.

Richard explains the idea behind SwingLabs, the chances for some of its work to be incorporated into Java 7, what he would do differently, and his side of the story behind SwingX painters.

There's also an interesting exchange, that shows up even more prominently when you open Kirill's earlier posts in their own tabs. Back in Sun setting down on the core Swing, Kirill wrote:

I think that core Swing has become a victim to Sun's outdatedly rigid policy on the backwards compatibility. I have written about this topic in the Substance users mailing list a few weeks ago.

Keep that in mind as you read Richard's reply to Kirill's question about whether maintaining backwards compatibility has unnecessarily held back Swing:

No I don't. If you gave up backwards compatibility you'd have a whole other set of issues that are many times worse. The level of risk one developer is willing to take isn't the same as another. For every one person who wishes we'd ditch backwards compatibility there are another 50 that would be violently opposed when that advice rendered their applications (or development of future versions of their applications) inoperable. Especially with a technology as mature as Swing.

To those people who say we should make a Swing2 which is not backwards compatible, I would say, this is exactly what we're doing with JavaFX.

The idea that JavaFX is effectively Swing2 is an interesting one, and recalls the earlier argument that adding things like properties made more sense in a new language (e.g., JavaFX Script) than as another change to the Java language. But does that mean that Swing is frozen and JavaFX is the only future? Richard points out that JavaFX can be mixed into Swing apps and vice versa, so maybe that's not even a valid question.