Skip to main content

Be Safe

Posted by editor on December 8, 2008 at 7:17 AM PST

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.

In another discussion timed to coincide with last week's release of JavaFX 1.0, and featured in the Java Today section,
Artima's Frank Somers interviews Sun's Octavian Tanase on JavaFX. "In this interview with Artima, Sun's Octavian Tanase explains how JavaFX helps designers and developers work closely together, and what types of applications JavaFX is especially suited for."

The latest edition, issue 186 of the JavaTools Community Newsletter is out, with tool-related news from around the web, announcements of a new community project, a reminder about the JavaOne Call for Papers, and appropriately enough, a Tool Tip on how to have a presentation accepted at JavaOne.

This week's Spotlight is on
JavaFX 1.0, which launched last week, and about which you can find more information at There you can watch an introductory video (presented via JavaFX) from Sun's Eric Klein, check out some demos and samples, catch up with the team in the JavaFX Blog, and of course, download the SDK, optionally bundled with NetBeans 6.5. Also check out the openjfx project on, for more news, demos, and information on JavaFX's open-source status.

Carol McDonald shows off a JavaFX RESTful Pet Catalog Client in today's Weblogs. She says it's "a JavaFX application that displays pet photos retrieved from a RESTful Pet Catalog app. This JavaFX example is a modification of the Interesting Photos : JavaFX Example Application."



I wouldn't say that JavFX is Swing2. JavaFX is to Swing what MFC was to Win32, just in the next level. Lets just hope that you won't have to go down to the underlaying layer as often as you did with MFC.. Or at least that it is as simple to do so like it is/was in MFC.

I suppose it depends a lot on whether you have a lot of code invested in Swing or not. So you're saying we were right to be worried over Swing being deprecated or you're not sure? If the editor of doesn't know what his own company is doing, what they're planning how do you think us developers feel? The FUD steams from a lack of communication with your most precious resource, your developers. Technically it's hard to leverage JavaFX from Swing, firstly your users have to have the latest runtime, secondly the APIs to use JavaFX from Java haven't been written yet and last I heard we (might) here more next year - so you guys don't really need help spreading the FUD, well the UD at any rate. The issue over properties is only half-finished. The upshot of not putting properties into the language is that it's pushed the binding/conversion support code from your swing models and into your domain objects which is absolutely the wrong place for it and ends up saving very little in terms lines of code. With the runtime detection (and the runtime install base is where this battle will be fought) detecting the active plugin is likely to give a false impression with developers. I've got about five runtimes/sdks installed on my machine. All our products and customers will be 1.5, 1.5 is my main SDK. However my IDE (IDEA) runs on a bundled 6.0.u5 sdk but I've installed the jre 6.0.u10 and plugin for demos & web browsing. It's the least used and least important to me, but the one the script will detect. Don't think I'll be unusual in this kind of setup.