Interview with Danny Coward: Swing has a bright future
1) In times of renaissance of the rich clients, some may be surprised that Swing was put off for such a long time. What are the reasons?
Actually, what has changed is that we are putting more effort into our richclient technologies, which includes Swing. We've already made some bigimprovements in the Java SE 6u10 release to make the runtime Swing uses morenimble.
And we are planning to add a major new API to Swing called the ApplicationFramework being done in the JCP in JSR 295. We also have a number of communitycontributions like the XRender project, date picker and CSS Styling functionality we would like to include in JDK 7. If you add all this up, itsmore API features than we added in Java SE 6. I think perhaps the focus we alsohave on JavaFX sometimes creates a false impression of the continuing work we're doing with Swing for JDK 7.
2) In your blog you mentioned that Swing 2.0 should be Java-based, notJavaFX-based. What does that mean or rather what does "JavaFX-based" mean anyway?
We have a highly successful GUI programming model based on the Java languageand the Swing APIs. Its great for more traditional GUIs like limewire. But the truth is that for the next wave of web-based rich client applications, which have been influenced heavily both in style and creativity by web applications, the developer-designers that create them have not been choosing Java and Swing to build them. We wanted in addition to Swing a new way to expose the underpinnings of Swing: the graphical capabilities and scalable Java runtime, to this new wave of designer-developers. So we now have, in addition to Swing, JavaFX, which we think is highly appealing to this new wave of designer-developers.
3) Wouldn't you agree that Swing will soon become a legacy technology besides JavaFX?
No, and for a number of reasons. Applications like the PC iTunes client show us that there is still a strong need for traditional GUI applications based ondesktop-centric GUI toolkits. And we need Swing to build applications like that. Second, the underpinnings of Swing:
graphics and the desktop runtime need to become yet more nimble both to benefit Swing and to benefit JavaFX: faster download, upgrade and execution of applications. And thirdly, JavaFX (and other new GUI frameworks like the Groovy based Griffon) depend on many of the Swing components - for example, see the javafx.ext.swing package which depends on some of the more familiar Swing componentsas part of JavaFX 1.1.
So while the role of Swing is changing, I think it has a bright future !
4) How will a relationship between Swing and JavaFX look like?
JavaFX and Swing share a common underlying runtime and graphical
JavaFX also depends on Swing for some of its core desktop-centric features like some of the UI components. Where JavaFX and Swing differ is that Swing is the toolkit of choice for the more traditional desktop-centric GUI application which tend to be created by Java developers, while JavaFX we think will be a highly appealing technology for developer-designers who tend to have a more artistic bent, and less of a formal training in programming languages.
5) Strange to say, Swing never had the ability to free itself from prejudiceslike "It's ugly" or "It's slow", though there are many examples that prove the contrary. What in your opinion are the reasons for this phenomenon?
I think technologies that are popular always have detractors !
In the early days, Swing was slow. Despite the fact that we have
improved Swing to the point where this is now an outdated statement
- through advances in the JVM, to optimisations in the libraries,
to use of the native graphics acceleration where we can (like
Direct3D on Windows), possibly some people get stuck in older
truths. I haven't heard the 'ugly' moniker for a long time. We just
released a beautiful new look and feel for Swing as part of the
Java SE 6u10 release, called Nimbus. It uses Scalable Vector
graphics to render the visuals, so looks great at any
6) Today Rich Clients are often built with Eclipse RCP, which is SWT- and not Swing-based. Did the Java-Swing-World miss this important change or does SWT have abilities that Swing doesn't have?
I haven't used SWT much, and it was created as a competitor to Java's AWT on which Swing was later built in the late 1990s. In general, I think competition is good in the world of technology: the competition between Eclipse and NetBeans I think has made both technologies better - they have begged, borrowed and stolen great ideas from each other making two great development environments, and really brought the Java IDEs on a par and even ahead of theMicrosoft tools. I think the more interesting question is whether the Eclipse team will create a Java-based RIA technology like something like JavaFX for the RIA space in order to help Java, which IBM and Sun are both champoins of, better compete with Adobe's Flex and Microsoft's Silverlight technologies.