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."

Rémi Forax tries Using Tatoo as front end of javac. "ANTLR guys are able to use an ANTLR generated parser as javac front end. Let's do the same with Tatoo."

Finally, Eamonn McManus introduces
Client context in the new JMX API. "I've mentioned in the past that one of the new features in version 2.0 of the JMX API is "client contexts", which will allow a client to communicate context information to a server, and a server to adjust its behaviour accordingly. The most obvious example is locale, where for example the client says that it is in the French locale and the server translates its messages and descriptions into French. How does this work? Read on."

In today's Forums, aalmiray asks about JavaFX licensing implications in Re: License question (UPDATE). "Now that JavaFX SDK 1.0 has been released, its runtime uses project SceneGraph but it s licensed under the JavaFX license (which is not GPL). Does this means that Project SceneGraph has changed its license too?"

Also concerned with licensing, wwilliams acknowledges an answer in
Re: JXTA License with respect to dependent libs.
"Thanks for the response. I don't necessarily have any concern with the Bouncy Castle license but your response has cleared up a few things up for me. The only reason why this even came up as an issue was that I just recently submitted a talk to EclipseCon and a few of the Eclipse developers mentioned legal issues of using JXTA at Eclipse (IP approval and provenance issues of JXTA dependent libs, specifically Bouncy Castle). This of course is none of my concern and I'm not asking you to address this specifically but I just wanted to be sure that my project was not in any violation of copyright and/or license agreement."

uvoigt would like to
Set a renderer for each column in JXTreeTable. "How can I set a different renderer for each column in a JXTreeTable? I only found the method JXTreeTable.setTreeCellRenderer(TreeCellRenderer). This does not allow me to set different renderers for each column or class."

agoubard grinds some different versions in the long-running thread
Re: Tracking Java Versions using Google Analytics. "I've also recently been tracking Java versions using another method. [...] Conclusion: Most of Mac OS X users still use Java 5. Most of Windows users use Java 6. 10.8 % of installed Java are Java 6 update 10."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The way forward for Swing, SwingX, and JavaFX


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.