Skip to main content

Swing 2.0 is Coming

Posted by opinali on September 23, 2010 at 4:07 AM PDT

The biggest announcement - and the biggest surprise for many - of JavaOne 2010 was certainly Oracle's new plans for JavaFX 2.0... or, should we say, Swing 2.0?

The history of JavaFX has been contentious since its beginning, when it was clear that FX was a new toolkit, even a new platform, while most people in the brave Swing community wanted a "Swing 2.0". Well, this is basically what Oracle is planning to deliver with JavaFX 2.0 - minus the ugly legacy of the AWT/Java2D/Swing APIs and architecture. JavaFX 1.x was an ideal replacement for Swing, but ideals don't always work; JavaFX 2.0 will be a more pragmatic attempt at "Swing 2.0". It's just not a drop-in update. Swing code won't be trivial to convert. The announced "plugin3", capable of running Prism, will be 100% free of AWT dependencies. Swing interop will keep requiring using the JavaFX Swing toolkit: the one that's bigger and slower.

Non-evolutionary changes are sometimes necessary. The old UI APIs take my blame for Java's near-death on the desktop & web. Don't dream that the problem was just Sun's neglect, could be fixed by new VM optimizations, deployment improvements, JDK 7's Jigsaw... or the Tooth Fairy. As the partial success of the JDK 6uN project demonstrated once again, no amount of tuning or fixing can save Swing. Even in the Swing community, many wished for a compatibility-breaking Swing 2.0 that would just be similar enough to allow easy migration and interop.

From EJB 3.0 / JPA to the most-wanted JSR-310, experience shows that sometimes enough is enough: the only way for frameworks that didn't work, is the highway. This tells me that some people have double standards when they strongly oppose JavaFX because it's not a smooth update for the existing Swing ecosystem.

R.I.P. JavaFX Script

The JavaFX Script language was the big casualty of the new plan, and I will heartly miss it too; that was quite a fun language to play with. But maybe that's mostly because Java was, and still is outdated. Even Java 8, with lambdas and all, won't be as nice as JavaFX Script (at least for UIs).

Some people will be quite happy creating JavaFX applications with the Java language (even Java 6). Plan B is relying on alternative languages such as JRuby, Groovy, Clojure or Scala; the Scala examples look really good, often hard to distinguish from JavaFX Script. If Scala is extensible enough to build some sugar for JavaFX's binding, I'm sold.

Dropping JavaFX Script has some advantages of performance and footprint. JavaFX 2.0 promises improving on 1.x even with its much bigger feature set. If that looks hard, it's easy to understand: first, Prism is more lightweight than the Swing-compatible toolkit. Second, JavaFX Script tends to produce bytecode that's quite bloated, and a bit slower than equivalent Java code (in one experiment, I got a 4% speedup by simply rewriting a trivial POJO-like class in Java.). These inefficiencies affect both application code and parts of the JavaFX frameworks, originally implemented in JavaFX Script - not the perfect tool for the job. Finally, JavaFX Script was still work in progress: I was hoping that they would add more features, optimizations and refinements... but, time's up.

Some critics complain that JavaFX Script was a wasteful diversion, a science fair experiment. I think it was a quite cool language, and the barrier to entry pretty low to any competent Java programmer that would actually spend a couple days with it. And any new big framework needs many months of experience until you really get the concepts and architecture, understand the tradeoffs and performance aspects, and become capable of writing high-quality code. But language barriers-to-entry are more complex:

  • Any JVM framework is better developed in Java. I hate when I read (for example) about Clojure's persistent data structures, as I can't use that in my Java code (at least not in a smooth, natural way). So this great piece of engineering and innovation is locked in the small niche of Clojure fans. Nobody will be motivated to try the full Clojure package after a good experience using its frameworks from Java. From my own small niche of JavaFX Script fans, I didn't mind that others couldn't use JavaFX's awesome frameworks; but this tight coupling clearly didn't do JavaFX any favor. Lesson learned: Write system-level code with the system-level language.
  • Programming language adoption is black magic. Corporate push can only go so far - the developer community can be quite opinionated. But that community alone can also only go so far - languages / compilers / VMs are Cathedrals that typically demand enormous, long-term investment, very organized design and development. On top of that, add: leadership, evolution, standards, timing, luck... for example, I don't think Javascript would've stood any chance in a fair competition with VBScript. Javascript is much better, but it didn't win because it was better. It won because it was there first in a web that was already big, and still owned by Netscape. And because many years would pass before people really had to learn Javascript, to write complex Web 2.0 apps: that would be the opportunity for VB's argument, "it's familiar and Microsoft has a pointy-clicky IDE". Lesson learned: Proposing a new language is always a big risk.

JavaFX Script didn't realy fail, though; it taught us many interesting things, and it paved the way. The future JavaFX 2.0, coded in either "good old Java" or in some high-level DSL-able language like Scala or Groovy, will be a much better system because we have a very clear and concrete vision of the ideal way to do some things. It seems to me that at least part of this technology (the runtime, if not javafxc's code generation) can be reused in a new Java-compatible library they come up with now.

Not a Full Restart

I've seen some skepticism for JavaFX 2.0 plans, claiming that to be a new "full restart" so we'd be heading for another 2-3 years wait until JavaFX is again mature and stable (say, as good as JavaFX 1.3.1 or better). There are some important mistakes here. First, JavaFX 2.0's feature set is much bigger than 1.x. Had Oracle kept the previous course with JavaFX Script, the Roadmap would still be pretty good for next year: new concurrency model; footprint and startup improvements; GA and default Prism; texture paint (thanks!); much expanded CSS support (animations, grid layout); next-gen media stack; WebView (back from the ashes of JWebPane?); HTML DOM and extra browser interop; and a new batch of controls - complex, critical ones like TableView.

Granted, a few items here (Prism, new controls) were originally supposed to GA in 1.4, later this year. The Design Tool was also supposed to hit public beta now. But the major disruption of the new plan is the "black hole" of the next few months, at least until the EA or Beta ships; any code I can write today will have to be ported when 2.0 ships.  JavaFX Script will be maintained for some time, but eventually all code that uses the JavaFX Script language and/or the existing APIs will be legacy code (yeah, I see the smiles of Swing fans for the irony).

JavaFX 2.0 is not a full rewrite. The bulk of JavaFX is already written in Java, C/C++ (the runtime has significant native code), or shader language. Only the higher-level public APIs, like UI controls, are written in JavaFX Script (and I expect even these to rely on some Java when it gets though). Oracle will have to rewrite some parts of the runtime, but even that will be partially a port - I don't think Jonathan will ignore all existing code base and design, and write the new Button control from zero, laboriously coming up again with the same rendering and layout algorithms, etc.

Oracle won't start coding all the new stuff next week, when the team resumes from the JavaOne break. It seems to me that they have been working on the new plan for some time now. You can see in the JIRA that the JFXC project looks dead since June when v1.3.1 development finished; 1.3.2 work didn't even start. Oracle has already presented some demos of what JavaFX 2.0 will be, so the new runtime may already have a few months of work behind it - a rough early alpha, at least.  Two big-ticket features, the advanced media stack and HTML5 engine, will mostly integrate/wrap third-party projects; and while still not trivial tasks, it seems that work has started quite some time ago in both fronts.

Finally, JavaFX is increasingly less dependent on any programming language. Releases 1.2 and 1.3 started a big push to move as much content as possible to the FXD format, and to web-happy CSS stylesheets. The roadmap for 2.0 further the trend: animation and layout will be scripted by CSS (using standard CSS specs when available). I didn't hear anything about the FXD format, but I think it will also be maintained and improved. So in the end, we don't really lose much of JavaFX Script's nice declarative syntax. Support for these components - from the CSS and FXD parsers / internal metamodel (already implemented in Java), to the NetBeans plugin and Production Suite (already implemented in Java or native code) - should be unaffected by the transition away from JavaFX Script.


Some good news for Swing

Check Richard Bair's blog. It seems that Oracle / the JavaFX team are really keen to provide the best possible JavaFX-on-Swing integration. As I expected, there are hard technical difficulties with Prism, but it's possible that even these problems could be solved. Also, it seems that with the "standard" renderer (non-Prism, i.e. the default thing of JavaFX 1.3), the integration can be possible without enclosing JavaFX scenes in heavyweight components; that was very unexpected for me (I was sure that even the standard renderer would be very hard to mix with Swing's lightweight rendering) and it's very very good news too. In the most likely scenario, hybrid Swing+JavaFX apps will have a choice/tradeoff: either the standard renderer that can integrate smoothly with Swing, or Prism that has extra performance and capabilities but is handled as a heavyweight component. Either option, and remarkably the choice of both options, are much better than my previous understanding.

haha ... full circle (maybe a

haha ... full circle (maybe a spiral), coming back to good ol' Swing+ ;-) Hard to argue, isn't it, after years of driving into the opposite direction ..



Not a really FULL circle, but certainly a tortuous path...

...we could also mention the mobile strategy: in the first annoucement, JavaFX was primarily a new mobile platform, based on the recently-acquired SavaJe; but by the time of the first Preview release this idea was already abandoned (Desktop and TV profiles added; Mobile profile just a layer over Java ME), and right now even that mobile profile is in the limbo.

But I'm happy that JavaFX is moving... while there is time to move. Your Swing code still makes use of things like java.util.Vector because Sun was too freaking conservative to fix that in Java2, even though the repackaging from Swing 1.1 into javafx.swing caused much bigger source and binary incompatibility for existing code.

Notice also, it's not a "full circle": JavaFX 2.0 will not be Swing-oriented by any stretch. In the good news, you will be able to use most of JavaFX 2.0 features from Swing apps, and this may be good enough to deliver most of the "Swing+" goals: first-class media support (replacing old cruft like JMF), advanced animation and binding, even new accelerated graphics capabilities including shader effects (except Prism-only features). The media and graphics features will likely be restricted to embedded/heavyweight components, but that's not worse than other solutions, like embeding some JOGL scene in Swing components - and the lightweight rendering model is not compatible with a better solution.

But, on the bad news, these new features will not be designed with Swing's architecture in mind. See slide 14 here (Observable Pseudo-Properties), also the new Observable collections that will replace JavaFX Script's sequences. This tells us that the binding and animation packages will not be geared towards pure JavaBeans (like Kirill's Trident, or like the old Beans Binding). You will still be able to adapt existing Swing code to benefit of both features, but that's a gap even if a minor one. "Pure" JavaFX 2.0 code (that uses JavaFX-specific APIs and controls) will be cleaner; for example a container's children nodes will be exposed as a JavaFX observable list, so you will be able to hook binding or animation code into that list more directly, without the extra wrapping or boilerplate that an equivalent Swing+JavaFX app will probably need. Maybe not a big deal - hopefully, because the more JavaFX can benefit the existing Swing ecosystem, the better. Just don't count on Swing to be treated as a primary, first-class customer of the JavaFX 2.0 features.

Too Little, Too Late

I don't think JavaFX was based on SavaJe. From what I remember from SavaJe, it was an attempt to migrate several Swing APIs to mobile devices, which was a great idea. Too bad they ran out of funding. JavaFX seemed barely compatible with Java little on having any remnants from Swing.

I'm still confused at how you can list JavaFX in the same context as Swing when JavaFX doesn't have most of the basic components needed to be successfully used as a GUI toolkit. Also, you don't code it in Java or Javascript, so Sun wasn't catering to Code Monkeys OR Tag Monkeys.... who were they targeting with JavaFX, then? They alienated Swing developers by not providing a simple API to utilize JavaFX inside of Swing containers. If they would have provided those APIs, they would have a lot better reception with Swing developers behind them. That left them trying to convince who to switch to JavaFX? Flash developers? Yeah... that would work. ("Come use JavaFX... it's more better than Flash... next year we'll add a table widgit.")

Here it is 2010. Where did BeansBinding go? Where did the Swing Application Framework go? I needed those APIs 10 years ago, and they still aren't here. Now it doesn't matter if Oracle backpedals and offers APIs to embed scene graphs in my Swing apps. It's too late. Our business users do want flashy transitions and a little eye candy, but they want them on their iPhone's and iPads. We're in the process of retooling, and JavaFX isn't in the ball game. The sad reality is that neither is Swing or Java.

I didn't say that JavaFX was

I didn't say that JavaFX was based on SavaJe, I said that was just the initial annoucement and plans, but they quickly changed that course.

On not having some components etc yet: for the 1000th time, I never claimed that FX was already complete. I wouldn't myself pick it for a business GUI (even a flashy one) before Oracle delivers things like TableView, makes deployment more flexible (offline runtime) etc.; totally agreed. I just think that the potential is certainly there: on every single thing that is already implemented in FX, it's better than in Swing... way better. The missing pieces are being added (even though not as fast as we'd like).

I suppose that the initial target audience was "RIA developers", whatever that means :) maybe the same people who were defecting Swing in favor of alternatives like Flash/AIR or Silverlight. Plus of course (with JavaFX Mobile), those moving to Android and iOS. And TV, although that's still a niche profile.

Both Beans Binding and Swing App Framework turned into independent open source projects; if the Swing community is really as big as claimed, I guess these projects will have many committers and will quickly deliver great releases, so what's the problem - just the non-core status? This didn't prevent millions to adopt Hibernate, Spring, tons of Apache libraries... and as a Swing-centric app framework, some people are happy with the NetBeans RCP. To me, it seems that the big gripe with the exclusion of JSRs 295/296 from Java SE 7 is that Sun sent a clear message that Swing is the legacy, not the primary toolkit that's worth of major new features included in the JRE.

JavaFX as Swing 2.0 ?? It will not work.

From time to time you are in the mood of shocking Swing people? I hope that your Swing 2.0 blog is totally your opinion, not official Oracle information. Otherwise we will loose again precious time and the next JavaFX try will end like the previous but another 5 years later.
OK, next year they get away with that superfluous language just for GUI programming.
But: if the next JavaFX thing they create is not just an extension for Swing to display Web content (Webkit), some movies (mainly for video help), display Pdfs and be able to fill Pdf forms, display many different (professional) charts, bring data binding to Swing...
than it will be another failed try, and maybe the last for desktop Java
The main feature for JavaFX is that it has to be fully compatible with Swing
Another very important feature would be that it has to be able to generate an almost native GUI so that you cannot tell it easily away from native apps of the platform. What I saw until now from JavaFX looked always like a cheap imitation of a GUI. Even the best ones: like this. It looks like an online game but not like a technical application. This you could also do with HTML5. Swing is for web started native looking applications, or why do you think there was a year long discussion why SWT is better, because those three pixels in this or that control were wrong in Swing. If someone would pay you for a fancy design but it must not be HTML, you could use some Swing look and feel but this requirement is very unusual in reality.

The graphics stuff of JavaFX is very nice, but almost useless in most business applications. Especially in the times of SVG. So yeah, Oracle, provide a good SVG pane for Swing and everyone has what he needs. It is not worth the effort to learn a GUI that is far superior in the controls field. And there is not even a remote sign that they can somehow get JavaFX in smartphones or consumer electronics. Android, iPhone and Win7 phone use other toolkits.
If Oracle wants/needs to modernize the graphics underpinnings and replace AWT that will only work, if they port Java2D together with Swing to prism. No one will even consider to throw away millions of lines of Swing code and experience for a fancy gradient API that produces 'Fisher price' GUIs.

You want/need for some reasons RIA in Java? Apache Pivot is perfectly what you are looking for. Maybe in the future enriched by some multimedia controls from the remnants of JavaFX. No need for Oracle to waste resources anymore. Concentrate on providing Swing controls and modernize it evolutionary, not revolutionary. But modernize Swing! It is still the best toolkit for cross platform applications and has a huge ecosystem and many developers and customers. I would not risk that, otherwise Java will be completely dead on the desktop and many people would be seriously angry.

Not trying to shock... unless truth is shocking

I don't have inside information (except reading between the lines of JavaFX team's postings, JIRA bugs etc.). But see my reply to Jeanette; JavaFX 2.0 will indeed deliver many of the things you want, in a forma that's perhaps not ideal, but still very usable for Swing apps - including a powerful WebView component. PDF support not in the plans but I don't see that need, there are good libraries like iText.

On native LAF: That was also in my wish-list for JavaFX. Remarkably since 1.3., JavaFX has a very powerful stylesheet mechanism that can be regarded as a better equivalent to Swing's pluggable LAFs. Maybe they're just waiting for this mechanism to become even more advanced (2.0 promises even more CSS features), so they can finally produce a set of native LAF's with minimum effort (JavaFX's CSS support is even more advanced than HTML's).

It's not possiblr just "replace the AWT underpinnings". Swing is hopelessly dependent on too much pieces and public APIs from AWT/Java2D. Can't do any substantial change without important compatibility breaking.

I've taken a look at Apache Pivot. Extremely unimpressed, remarkably on RIA features. And even Pivot creates a full-new set of components, it's a Swing competitor nearly as much as JavaFX 1.x was, so I'm very amused that you have sympathy for Pivot.

Re: Not trying to shock... unless truth is shocking

Hi Osvaldo-

" I've taken a look at Apache Pivot. Extremely unimpressed, remarkably on RIA features."

What specifically did you feel was lacking? We on the Pivot team have focused heavily on the "I" and the "A" parts of the acronym but not so much on "R", so I wouldn't be surprised if you mentioned media features, for example. However, I'm curious to know what else you think is missing.



Pivot seems to do what it

Pivot seems to do what it proposes to do very well; seems to be a very good Swing replacement for applets. The problem is that Pivot is just another pure-Java library; without some native code it can't ever compete in both the advanced graphics and media fronts. You must build on top of AWT/Java2D, and you can't hope either to deliver much improvement in the critical isues of startup experience or performance as these depend on the core VM and browser plugin. The size of Pivot's runtime is also an issue, Pivot won't have privileges for bundling/preloading or plugin optimizations. I don't think the problem of web-side / RIA Java can be fixed by anything less than a full platform overhaul, and only Oracle is in a position to do that... Pivot may be a tour de force as a workaround, but I'm afraid this is not good enough.

Re: Pivot seems to do what it

Thanks for sharing your thoughts. Additional comments below:

"Pivot seems to do what it proposes to do very well; seems to be a very good Swing replacement for applets."

It's probably worth pointing out that Pivot isn't limited to applets - it can also be used to build full-fledged desktop apps (in fact, developers seem to be much more interested in using it for cross-platform desktop development than for building web apps).

"The problem is that Pivot is just another pure-Java library; without some native code it can't ever compete in both the advanced graphics and media fronts."

That's true to some extent, but again, media delivery hasn't historically been our focus. Pivot's main objective is to make building business apps easier, though we do try to incorporate visual interest when it enhances the overall user experience. Java2D has so far proven to be sufficient for this, but we'll certainly look at other options (such as Prism) if they become available.

"You can't hope either to deliver much improvement in the critical issues of startup experience or performance as these depend on the core VM and browser plugin."

True, but any Java-based UI platform will be affected by these issues.

"The size of Pivot's runtime is also an issue, Pivot won't have privileges for bundling/preloading or plugin optimizations."

Pivot's JARs are pretty small. Even with debug info, they only weigh in at about 2MB, which is negligible for a broadband connection (and far less than the size of the JRE itself, which over the past couple of years has been updated quite often). Also, not every app will need all JARs, and they will be cached once downloaded. So this isn't really much of an issue in practice.


Not trying to shock... unless truth is shocking

on native LAF stylesheets might be enough for a talented designer to create a convincing enough look. But how does JavaFX handle differing feels? how is it on focus control, keyboard entry, hotkeys/shortcuts/inputmethods, component orientation all feed into an OS feel & locale.

Not every technically good idea is feasible

PDF: Swing needs a possibility to display a PDF and to fill PDF forms. iText is only for pdf generation
Native F&F: Yes I know the CSS support, quite impressive. But not native. Modern Swing implementations (eg. from Apple) use the native components. This you need, otherwise Apple will block that I guess. They want native look and feel. The recognition value is king for them. Also many customers want native look and feel for their platform. The other possibility are Web-Application in the browser. But thats HTML5 in the future.
Port: I do not know, how urgent it is anyway. I mean Swing functions very well, there are just a few components and data binding missing. It is a complex beast, yes, but with a simplifying lib on top of Swing (a Swing application framework) everything would be fine (even including some out of the box animation effects). Swing can not be used on consumer electronics, granted, but all Smartphone operating systems already have their GUI toolkit, anyway.
Desktop Java in reality means in house business apps, scientific apps or engineering apps. Just take a look at this . There is not much need for animation in a database front-end. These are no consumer apps from Apple. The Java3D on hold, because of JavaFX, is much more a problem. At least for us.
So JavaFX might have made sense for consumer devices, but there are none it seems. But it is the wrong API for the applications Swing is used for.
Pivot: It is not Swing, yes. But it is available here and now and can be used for quick assembly of simple declarative GUIs. More is not needed for desktop Java in reality, so Oracle can save its resources to fix Swing and Webstart bugs, provide a resolution independent Swing and work on faster startup times of the JVM.

PDF and native LAFs

PDF: The problem is that PDF support is a HUGE, complex feature. iText even being write-only, is a 1,6 Mb jar. Quite massive to add to the core libs... and when you do that, some other people will complain that Java should also have nativew support to read and write ODF and MS Office files (both legacy and OOXML for the later of course). These features are all niche enough that even a standard extension (not bundled in the JRE but JCP-standard) doesn't make much sense... they are also moving targets, controlled in a non-open way by other companies (only exception being ODF), may have important security issues to worry about...

Native L&F: I don't think Apple's OSX LAF is really native in the sense of using native components. More likely, they just optimized the core (AWT/Java2D) to effectively use the Quartz APIs (just like Sun did for X11, DirectX, OpenGL, DirectX, now XRender...), and the rendering code of the proper Swing LAF for fine rendering details. You don't need honest-to-god native components to produce a LAF that is exactly identical to the native one... you just need performance, this is where Swing still fails, and JavaFX succeeds with its full-accelerated rendering for everything including UI components (especially Prism). Notice btw, that a modern native LAF for platforms like OSX and Windows (Vista/Win7 and beyond) requires to emulate the increasingly sophisticated look of these OS'es, with complex animations (including fake-3D), composition effects (translucency/blending/mirroring), etc. AWT/Java2D/Swing simply can't dream to do these things with adequate performance. But JavaFX will be able to do it effortlessly, so it's the only option if you really care about native LAF. (Except Eclipse's SWT, the only option that really uses native components, but that's a debate for another day.)

Re: PDF and native LAFs

PDF: There is a demo version but as every big desktop Java announcement not finished. Its 2 MB. With project jigsaw it should be no problem as it would only be loaded when required. If you download and install Java I do not care of the size anyway in times of terabyte harddisks. ODF support would be very nice yes. I think it is nearly a marketing requirement, given that Oracle also owns OpenOffice. One has to compare to other toolkits. E.g. Cocoa includes Pdf, Word and Rtf support

Native L&F: As most things with Apple, their Swing implementation is closed source. But slight adjustments to their L&F are immediately followed by Java. They stated in their mailing list that they use Cocoa code for implementation (including some non public APIs). There are also some differences in Apple Swing as compared to Oracles Swing that hind to the tight integration in Cocoa. You also can mix Cocoa controls and Swing controls. It looks to me indeed that much of the Apple Swing L&F is implemented using native code (including pseudo 3D effects). I think this is increasingly also the case for Oracles Swing on Windows. The old argumentation of the SWT people that they have more native controls holds not true for todays Swing.
I thought that the current Java2D pipeline is also using OpenGL. There were always those artifacts on some machines because of old graphics card driver, remember? Especially for the lightweight components why should it be a problem to further optimize speed. But working with netbeans, idea or jEdit these days shows that Swing has no speed problem any longer. So that is really no rational to completely start over again.

PDF: Jigsaw should indeed

PDF: Jigsaw should indeed allow throwing the kitchen sink in the core and not have installation or loading time issues; in fact, we could even argue for elimination of the barriers between Java SE, EE, FX, and even non-Oracle/non-JCP frameworks - just modularize the world, then each app loads (and if necessary installs on demand) whatever modules it needs. But in that case, why should Oracle and/or the JCP put things like PDF and ODF under their umbrella? Except specific cases like ODF (really makes sense as Oracle owns OOo), we're better off with a Linux-like system where the core platform contains a good module system, configured by default to connect to a "root", curated repo of Oracle/JCP-approved third-party modules, but you could always override that to fetch modules from other repos from Apache, Redhat etc.

Native L&F: My point was that Apple's Swing controls are not mapped to the native controls, i.e. it's not like you create a JButton and Apple's LAF will call the OS to create a Cocoa NSButton and just wrap around it. This is what both the AWT and SWT do (in different ways), but Swing LAFs can't possibly do that AFAIK. Apple's LAF should certainly be using native code and native APIs, but I believe that this should happen at the AWT & Java2D level. At the Swing level, most likely they just have some extra OS integration for fine synchronization with OS UI preferences and resources, and desktop integration.

Swing 2.0? you wish

So in your opinion its perfectly acceptable to pitch all the applications, libraries and components written in Swing not to mention the dedicated developers who sweat blood on such a broken useless API for so many years into the bin*? Should those developers just shrug their shoulders and get to work rewriting their apps into [strike]JavaFX Script[/strike] JavaFX APIs. Do they not have a right to feel angry and betrayed at all? after being treated so shoddily once already why on earth would the consider moving to your so called Swing 2.0? You place the failure of desktop Java at the feet of a development API? Id say it was more the users who didnt want the confusing deployment and upkeep of the Java runtimes and care for fat clients for much the same reasons. Rewriting Swing wont be appreciated by users, its of no concern to them, JavaFX will no doubt end up looking like Javas new cross platform look & feel.

(* bin being some second class jigsaw module kept around for legacy support)

Swing 2.0? you wish. You claim JavaFX 1.0 was a suitable replacement for Swing, which is plainly wasn't. Even the latest 1.3 hasnt got the full complement of the most basic Swing components, let alone the huge catalog of community components. I'm sure the Netbeans platform guys will be particularly pleased to be considered failures. How many Swing apps are in use at the moment compared to JavaFX? How many of those apps really need 160 media streams rendered as a rotating sphere? Looking at the winner of the latest JavaFXpert RIA Exemplar Challenge its clearly been years of effort well spent.

You say "ideals don't always work" and "the only way for frameworks that didn't work, is the highway" and I agree. In its relatively short life JavaFX Script and JavaFX the platform has shown a distinct failure to launch. Its much touted "for all the screens of your life" tagline has proven hollow - its never been further away from any penetration into the mobile markets or the 'billions of handsets' it was originally pitched at. Now its stripped of its elegant declarative language and trying to ape what little success client-side Java ever had on the desktop and largely at the expense of its existing community. It all seems too little way, way, way too late.

Fear is the path to the dark side... ;-)

I fully understand the problem of existing legacy, skills etc. I have a big JavaEE app, built with EJB/CMP (yeah my client forced that choice in 2006); CMP was just as bad as expected from its fame, then over the years we worked around it by writing all sensitive queries and even some DMLs with pure JDBC - so the whole thing is now ugly even with patterns like DAO to contain the mess. Now the client finally agrees to migrate to JPA, but that's a big change on a system that is now mission-critical. You seem to be the kind of developer that would say: "Screw you Sun, JPA sucks because there's no smooth upgrade path from CMP". I am the kind that says, "Thanks Sun, you f***ed up pretty bad with CMP a decade ago, but at least you've fixed it, JPA is great, my next projects will have great persistence at no cost, current ones can still be salvaged at some cost".

I blame a big part of the failure of desktop Java on its UI toolkits/frameworks. But I don't blame the designers of AWT/J2D/Swing, because portable UI toolkits are an incredibly hard task - Swing is arguably the best such toolkit to date. We didn't have current JVM and GPU technology back in the 1995-1999 timeframe. Even non-portable toolkits are hard to evolve across generations of graphics technology, see for example Microsoft .NET (WPF -> Silverlight).

I didn't ever claim that JavaFX 1.x was already a full replacement for Swing. That was the plan, but some pieces like extra components still had to ship.

The NetBeans platform, as I understand, is more acout an RCP / application framework / modularization, than about Swing. JavaFX 2.0 will not replace that; it doesn't include a full high-level app framework. It's even possible that the NetBeans platform can be adapted to embrace pure-JavaFX apps (I have no idea if it is too coupled to javafx.swing APIs).

Fancy demos are just technology showcases. I don't think I will ever want 160 media streams in rotating spheres; and I guess that this demo should max out a modern GPU, wouldn't run that well in real people's PCs with crappy Intel video. But if JavaFX 2.0 can do that, it can certainly run the more modest multimedia requirements of business apps (or even "normal" RIAs) running on average hardware.

Not fear more bemusement / resignation

That where we differ then because I understood JavaFXs aim was to build those rich applications that weren't straightforward with Swing. Actually the original discussions said it wasnt for developers but for designers, JavaFX script would all be generated by tools - not hand-coded. But Swing would continue being developed, and in fact had a bright future. Especially with language level properties for binding that would benefit both Swing, JavaFX and generic Java (inc JEE). JavaFX apis would also enhance Swing or so we were told. The reality now is of JavaFX 2.0 pushed as a rewrite of Swing (because the mobile plan is a bust?) and the old Swing/Java2D apis are nothing but an embarrassment holding us back. All of which has foisted upon us without any real discussion or warning (unless you include cold indifference), BTW where is Chris Oliver these days?

The reality is for every flashy multimedia UI theres dozens of average enterprise application, thats what the Swing people have been asking for make it easier to build our boring database frontends. In my 10 odd years as a Swing developer I've never been asked for rich animations & fade effects. I have been hauled over the coals a number of times for wasting time on cometic changes like icon schemes or alternate look&feels. Most application requirements can simply be fulfilled with basic platform HID compliant UIs.

I think Im pretty pragmatic, we never touched CMP and our last EJB app was in 2005 and that was XDoclet & Hibernate. When I see JavaFX its all very nice, but we dont have any pressing need for its wizzy GPU features. On smartphones & tablets yes, that'd be brilliant. Thats where all the rich innovative applications are hanging out, the desktop? the corporate desktop? not so much. It seem the wrong APis are being pushed in the wrong places. Even if there was a demand for rich Java desktop apps, and I'm not convinced there is, I'm not about to gamble on JavaFX finally delivering on promises that've been repeatedly made and broken so many times in the past.

Building RIAs was indeed a primary objective...

Building RIAs was indeed a primary objective, but JavaFX always planned to be a full-blown UI toolkit, including all sorts of "business-oriented" controls; these came later (are still coming). I don't see any incompatibility between these goals. You can have a single toolkit that allows to build both corporate CRUD & reporting forms, and multimedia smorgasbords, games etc. There's even a pretty nice charting package included. Maybe they should have planned the development with more priority to deliver all business-centric features first, but that would also be a difficult strategy because the first releases would be a 1-to-1 replacement for Swing, but a less mature replacement and without many revolutionary extra features to differentiate.

I don't think the status of mobile Java (either Java ME or JavaFX, both are in the same boat) had anything to do with JavaFX 2.0. Whatever the profile, I think they just decided that the burden of the JavaFX Script language (including harder migration/interop with existing Java code and APIs) was bigger than the benefits. In fact I won't be surprised if Oracle manages to salvage Java ME, and comes up with a new JavaFX Mobile 2.0 that allows some interop between JavaFX and Java ME, including AGUI / LCDUI / LWUIT.


Swing 2.0?

Hi Osvaldo,

I would love to think about this Oracle moviment as Swing 2.0. But, I'm not sure about this, cause I understood this as just "you can use JavaFX in some old Swing container". Of course, this is better than nothing.

But, IMHO, the real improvement in Java/Desktop could be: sometime in the future, when the closures becomes real, rewrite the event model; and all old desktop thing lost by Java in this years, like real support for paralell ports, USB, real and updated multimedia (I wrote a little mediaplayer some days ago, using the JMF, and it's a pain in the ass). Ok, the last one will be addressed by JavaFX.

And, the last but no the least: great article.

Swing X JavaFX 2.0 X JDK 7

I think JavaFX 2.0 will actually deliver an ideal solution for some of the old "Swing 2.0" wishes; powerful media support is certainly one of them, because the worst-case scenario is that we'll be able to embed any supported media inside a Swing component, including GPU acceleration (the lightweight/heavyweight integration is good enough for that), and have full two-way control over that (media markers, animation synchronization etc.). This is already much better than any existing option like JMF. Probably not possible: combining that media to your lightweight-paingted JComponents; embeding Swing components "inside" the media; combining Prism's unique features like 3D support - but these were never even in the radar of Swing's wish-list. These extras, as well as the very best programming model (all APIs fitting perfectly together with less glue / boilerplate) will be an advantage of "pure" JavaFX apps, e.g. those that use its scenegraph-based APIs for all controls, windows, event handling etc.

Java 7 features can actually improve the existing Swing APIs, even without JavaFX 2.0; closures are an obvious item, they can put all your listeners on a lines-of-code diet. I suppose that JavaFX 2.0 and Java 7 plans will be carefully matched, remarkably now that Java will be the primary language for JavaFX, that will exploit both existing features like generics, enums..., and new ones. The EA reelase of JavaFX 2.0 will probably ship very close to the first RC-quality builds of JDK 7 (with feature-complete Project lambda); and the Beta may ship close to JDK 7 GA.

On USB etc... yes that's a shame, but a completely independent issue that neither depends nor benefits from JavaFX. Oracle has made some gannouncements about future unification of the JavaME profiles; maybe this could result in something like: add JSR-197 (GCF package for Java SE) to JavaSE 7.


About USB and related stuff: I known it's not related to JavaFX... it was just some crying in the rain :D