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 JavaFX.com. 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 java.net, 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."