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.
Swing 2.0
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).
The Sun Setting on Swing?
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.
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.
The 80/20 Insight
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?
I agree. The point of having libraries is to avoid writing the same code over and over (although that's a 'good' way of getting a paycheck). Things like data binding are very important, because they minimize the amount of code to be written by a large percentage. Developers are more likely to use the environments that offer those helpers instead of doing the boring stuff manually.
That's one of the reasons my colleagues keep mentioning the 'data window' of PowerBuilder.
Definitely. They're wasting their time on a technology that probably few people will use instead of fixing a technology that's mature, stable and used by many enterprises. A lot of things could be fixed in Swing such as the JFileChooser and the many bugs not fixed.
Even though the economy doesn't look good, Sun needs to get new blood to re-energize the client development world. I hope Sun will continue to be good stewards of Java the language. They should continue to make Swing better and better. Many customers are just beginning to look and learn about RCP frameworks in Swing. Sun should continue to have two teams. I believe that both are very different technologies at different levels. In the Microsoft world, some would build MSAccess applications, some would use VC++ Win32 API, some would use XAML, and some would use SilverLight. I hope Sun doesn't abandon Swing. I think that would be a huge mistake. Unless I'm missing something. This is just like abandoning AWT for Swing. We need great high performance graphics (2d,3d, sound, video, media codecs, jogl, scene graph, JNA, JDIC, blue-ray) along side Swing. Now if they can do that with JavaFX that's cool too. Sun needs to deliver what they promise. Finish what you start. JMF, JSRs, Java3d, etc.
Sun needs to build and sell awesome Swing or JavaFX Applications for administering their servers, databases, etc. I think Sun needs to start making money from their own language. Don't let IBM, Oracle, Weblogic have all the fun. Take a play from the Microsoft playbook. JavaFX is very promising, but still too new. Ok, so what if Guy, Haase, Violet, Muller, etc. left? I'm sure there are many who can fill their shoes. I think Sun needs to hire an army of great Swing consultants to contract work to build great software. If Sun wants to be a software company they better act like one. It's nice to talk about how open you are, but until you use it(software) it is of no use. Create a great magazine publication that has both Swing/JavaFX/NetBeans show casing all things you can do from a Flex/Flash, MSAccess, VB, Photoshop developer perspectives.
So, to answer the question. JavaFX doesn't hurt client side java, but when Sun stops development on client side java to build a new language and window tookit, that could make people loose faith/loyalty in Java all together. It's like the many people who bought a Mac si/ci/fx to find out Apple decided to dump the 68k Motorola for Risc based chips. And back then a Mac si was $3000.00 dollars. The loyalty went out the door. (This happened to me)
i don't see any problems using jfx with java in the backend as well as doing the data binding in jfx. in fact, the data binding is in-built to jfx, so no 3rd party libs are needed or so... jfx uses a lot of other projects that are "abandoned" now. no one really forces you to create fancy looking ui in jfx... i see it contradictory to speak about swing and people around it (chet, romain) who tried to get swing to the next level (filthy rich clients) and then "complain" about fancy graphics offered by jfx. get real. although it's sad to see that sun is abandoning swing after all of the effort to improve it somehow (swingx).
I think it is too early to complain. Let them finish JFX, and let's see what they are bringing. Sun could always bundle JFX runtime with Swing and provide thin Swing wrappers over the JFX runtime. After all, it is a JVM language. If it is bundled with the JRE, I can imagine developers moving towards it; data binding and triggers are the two killer features that could convince some Swing developers to make the Switch.
The problem with client-side java (at least on the web) is the JAVA PLUG-IN. I am a fan of the JavaFX language. But the success (or lack there of) of Java Web clients is related to the quality and ubiquity of the Java Plug-in. Sun would have been smarter to take their investment in JavaFX and apply it instead toward creating a fast, small, reliable, easy-to-install Java Plugin for all popular desktime platforms (Windows and Mac).
This is the kind of behavior we have come to expect from Sun. They are late to the party with inferior technology and, because of that technology, they take their eye off the ball.
Our last Java User Group had two presentations, one on JavaFX and one on Flex. My takeaways were that JavaFX is vastly inferior to Flex, way behind, and off in the weeds regarding focus. Both presentations relied on existing demos but the difference was the Flex demos were useful and the FX demos were eye candy...and not such tasty candy at that.
Sadly, Java is in its decline and Sun is hastening it. Innovation is needed but it is being blocked (Bloch'd?). There are loads of ugly dingleberries hanging from the language and the JDK. V7 is nowhere in sight and many of the most useful things are not going to be included (if the thing ever sees the light of day).
> JavaFX and apply it instead toward creating a fast, small, > reliable, easy-to-install Java Plugin for all popular > desktime platforms (Windows and Mac).
Java 6u10 appears to deliver exactly that at least for Windows. The situation with the Mac is unfortunately, but at least Java is installed by default so the easy to install part is irrelevant.
> Innovation is needed but it is being blocked (Bloch'd?). > There are loads of ugly dingleberries hanging from the > language and the JDK. V7 is nowhere in sight and many of > the most useful things are not going to be included (if > the thing ever sees the light of day).
There is indeed a vocal community opposed to some (or all) of the proposed changes, but how many of them work for Sun? Within Sun progress on Java7 appears to be proceeding at a steady pace. Far from being "nowhere in sight" I have a build installed on this machine. Just yesterday there were seven emails from Alan Bateman notifying changes to the Mercurial repositories for OpenJDK7.
I'm mostly just an observer, although I do test some aspects of particular interest to me. I don't work for Sun.
java is far away from its declination. there're too many applications written in java that run across variety of platforms. jvm is the platform. we will use java for long time yet, unless some other language running on jvm will get in the way. in this case, most of the people wish to see scala as the next java i think. one more thing - i would not say that josh is blocking innovation of java, he just made another proposal.
My bad. I put two thoughts together that should have been separate. My gripe with Sun is the pattern they fall into like with JavaFX/Flex where they try very poorly to compete with an established technology, fail, and usually adopt the competing technology in some fashion within a JSR. The JSR part is fine but the opportunity cost is huge. I think the brain drain Sun has experienced over the last few years says a lot about what the technologists think about Sun's approach.
"Within Sun progress on Java7 appears to be proceeding at a steady pace."
Clearly something is happening. The important question is: When is Java 7 scheduled to be released and with what features? This is what I mean by "nowhere in sight."
A technology can be in decline AND be vastly diffused. I did not say Java would go away. I said innovation was needed but wasn't occurring.
I distinguished between what I call dingle berries and innovation. Dingle berries are things like putting CORBA or JAXB or JAX-RS in the JDK. Innovation is generics (although poorly implemented for the same reasons I am complaining about), j.u.concurrent, and annotations.
> jvm is the platform.
I do hope the platform lives on. It's great technology. I'm not ready to give up on Java but I feel there are some things lacking for the technology to stave off decline.
> one more thing - i would not say that josh is blocking > innovation of java, he just made another proposal.
My reference is to Josh's obsession with not wanting to change the core language any further. He has gone out of his way to block the BGGA proposal which IMO is innovative. He went so far as to come up with his own proposal - one that he doesn't even recommend - merely to undermine BGGA. His proposal falls short like generics falls short (although for different reasons).
We could argue about whether to change the language or whether to erase erasure (my two most wanted and least likely additions to Java 7) but that would take us off topic.
I think if you study the history of JavaEE you will see examples of what I am referring two where Sun futilely tries to "one-up" an existing technology, fails, and adopts through the JSR process. Opportunity for innovation is lost.
What's getting not said is the obvious (last said by Bruce Tate in public, long ago by me): java is COBOL. Sun went that way, and now has problem. What happens when Sun dies (I give them two years)? Who provides the bodies that Sun does now? IBM is the likely candidate. I see no way that java could be maintained by a gaggle of open source folk. All the other major languages have corporate angel.
What did IBM do to COBOL? They forked from ANSI early on. IBM would turn java into a WebSphere extension; there will be IBM java and open java. The IBM jdk is already different.
Where would client side java matter to an IBM javBOL? In particular, would IBM do anything different? Well, maybe. It is common knowledge (and true from my viewpoint) that the applet exists in corporate intranets. Few other places. IBM did the SWT. A java sponsored by IBM would likely be more interested in a quality client side technology. Whether that is Swing/SWT or javaFX or something else yet is not clear.
But those interested in client side java should be hoping for an IBM coup.
Flat View: This topic has 34 replies
on 3 pages
[
123
|
»
]
Previous Topic
