|
|
|
Sponsored Link •
|
Summary
Sun's focus on JavaFX has resulted in less progress on improving Swing development productivity. Has the shift of focus to JavaFX from Swing hurt the cause of client-side Java?
|
Advertisement
|
For almost two years now, Sun has been promoting JavaFX, the centerpiece of its vision for Java as a viable rich-client technology, and an alternative to Adobe's Flex and Microsoft's Silverlight. At heart, JavaFX is a JVM-based domain language for constructing rich user interfaces, as well as a set of APIs for that language.
While JavaFX can work well with Java code, it does not jive particularly well with its more mature Java UI cousin, Swing: If you have experience developing Swing applications or applets, you will need to learn a different programming model, API, and even different tools, to program in JavaFX. In addition, as far as I understand it, existing Swing components, such as JTable or JXTable, don't work out of the box in a JavaFX application, but need to be wrapped inside special JavaFX code. In other words, while JavaFX and Swing can work together, they are really two separate technologies for Java user interface development.
Swing has been around for a decade now, and there are thousands of Swing-based applications in enterprises, the context where Java is most ubiquitous. Its potential downsides notwithstanding, Swing has been an excellent choice as a user interface API for an enterprise application. The fine-grained, event-based programming model that recently became popular in the browser, has existed in Swing since Java 1.1. Swing-based components are, in general, easier to work with than Ajax-based ones, perform better in the presence of large amounts of data, and can take advantage of the JVM's multithreading ability as well as the full JDK APIs.
In recent years, Swing has started to show its age, especially since the advent of more recent UI toolkits, such as Flex. The Swing community, and Sun in particular, addressed some of Swing's wants with a new set of proposed API standards, open-source API projects, and by promoting how existing Java APIs, especially Java 2D, can make Swing applications look on par with Flex or Silverlight UIs.
Alas, many of those efforts have by now abated.
Several of the proposed new APIs aimed to standardize practices that the Swing community already had solutions for, such as data binding (see Artima's interview with Shannon Hickey, spec lead of JSR 295, Beans Binding). Other APIs addressed the general lack of clear guidelines for developing Swing applications. Foremost of these was JSR 296, Swing Application Framework (see Artima's interview with Hans Muller, past JSR 296 spec lead).
The SwingLabs project, aka. SwingX, is perhaps the most significant open-source project aimed to extend the standard Swing components and to provide new ones. Sponsored by Sun, many Sun developers contributed components to SwingX, such as an alternate Swing table component, a login framework, and painter and animation libraries, to mention a few. And many Swing-related projects sprung up outside Sun, too, such as JGoodies (led by Karsten Lentzsch), or the Substance Look and Feel (led by Kirill Grouchnikov).
In spite of a thriving Swing community, and despite Swing's large user base, Sun has re-focused its efforts around JavaFX over the past year-and-a-half, at the expense of Swing development. The most visible aspects of that change in focus is that many of the most experienced Swing developers left the company, such as Chet Haase (see Artima's interview with Chet Haase), Hans Muller, or Scott Violet. The important Swing-related JSRs have also been stale for a long time now: the latest JSR 295 and 296 updates occurred in June, 2006, according to the JCP's Web site.
Most recently, SwingX contributor Jeanette Winzenburg wrote on the project's online forum that Sun all but abandoned its support for SwingX, because its engineers are busy working on JavaFX:
... the official terminus is "frozen" - but as that happened already in July and everybody in the core team is well over their ears into FX it looks rather permanent to me...
I think it quite funny that [Sun engineer Richard Bair argues] in favour of that support/evolution mainly by stating that nobody (definitely not the experienced engineers/architects) at Sun has any time for it - because you all are wasting it it on FX (biased me again
) Fancy demos - especially in a language unrelated to the project at the center of this forum's topic - are just that: fancy demos. They don't solve any real world problems. Chet's termed the effort to produce them so cutely as CDD - Conference Driven Design.
Winzenburg's note seems to echo the sentiment of many experienced Swing developers. JGoodies' Karsten Lentzsch noted, for example, that:
I’m worried that Scott Violet, Chet Haase, and now Hans Muller left Sun. AFAIK Jeff Dinkins isn’t working on Swing anymore, and Amy Fowler has changed her focus too.
None of my Java customers is interested in JavaFX. They want to get their Swing UIs running. They are looking for Java desktop blueprints, for a cook book that explains how to address the everyday Swing task. My customers were excited about the JSR 296 (Swing app framework) and 295 (beans binding). But now it’s unclear what’ll happen to these projects. I don’t see Sun’s Swing strategy.
If you look at the JavaOne 2006, 2007 and now 2008 what have we got for Swing, or in other words for the Java deskop *now*? A cool demo (Aerith) in 2006, more cool demos in 2007, and JavaFX in 2008. All my customers do the “boring” stuff: editors, forms, navigation, buffering, data binding, layout. That’s how they make money. Who cares about them? They need a framework, better components, not animated 3D flipping images.
And Kirill Grouchnikov recently wrote that:
I don’t know what the future holds for JavaFX. Sun is heavily betting on it... All I know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX.
Over the past year, I developed a rather extensive enterprise application with a Flex user interface. Prior to that, I worked on an even more feature-filled Swing application. Both are customer-facing applications, with strict usability requirements. Based on these experiences, I can second Lentzsch' sentiment that,
All my customers do the "boring" stuff: editors, forms, navigation, buffering, data binding, layout... They need a framework, better components, not animated 3D flipping images.
To me, Flex has proven more productive than Swing, mainly because of the "boring stuff:" data binding, validation, UI layout, and integration with a Java-based backend are very easy in Flex. In addition, you can express UI states in Flex quite explicitly, a feature that turns out to be very practical. It is also trivial to deploy a Flex application in the browser or, with AIR, on the desktop. Although Flex has a plethora of features for doing fancy animations and "effects," I found those features unneeded, and even distracting, in a business application.
To stay competitive, developers need to seek constant productivity improvements. That's especially true for the enterprise environment, where not only is Java the most prevalent, but also where most Java developers work. The Swing initiatives that now appear dormant aimed to, in effect, bring Swing development productivity on par with Flex development. Except for UI layout (for which Flex has a domain-specific XML language), the Swing-related JSRs and open-source projects I referenced above would have resulted in Swing matching almost every productivity element in Flex. And the latest JDK update does solve the Java deployment issue.
It seems to me that keeping Pareto's oft-quoted 80/20 principle in mind would have benefited client-side Java development more than the features developed in JavaFX could ever do. Enterprise Java has long favored the "boring" stuff over niches, and it would have been wise for client-side Java to follow a similar path.
Do you agree that Sun's recent focus on JavaFX has hurt the cause of client-side Java?
Have an opinion? Readers have already posted 34 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.
 | Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit