Osvaldo Pinali Doederlein's Blog

Clearing the Java FX FUD

• Mobile support: LCDUI exists because Swing was too damn big, complex, white-box, and unfriendly to "heavyweight" (= lightweight, in Swing Newspeak) components; so a reasonable subset couldn't be cut for MIDP devices. What about AGUI? The timid success of the CDC configuration in the higher-end devices is not very commending of Swing either.

• Ease of Development: Swing's never got kudos for its learning curve. Arguably, this could be partially fixed by the Java language: if we had properties, closures and other goodies... but (unfortunately) we're not going to have those features even in Java SE 7. JSR-295 could help, but without properties, it would be a clumsy workaround (at least compared to Java FX's binding).

• RIA: Java2D is a great API but it's just too arcane to write graphically rich and creative UIs. Even before Java FX, traditional GUI APIs were defecting to alternative models that push the visuals to some kind of DSL, from Android's layout files to full-blown solutions like XAML.

Comments

• I'd add one thing. Many have raised their concern about JavaFX not being open source (yet?). F***, none of the alternatives are! And Java itself wasn't until very short time ago, and yet was a perfectly feasible solution for both the enterprise and open source projects (but the most radical fronts).

  But I really hope: 1) they release the SDK for Linux soon; 2) someone (I prefer an open source project instead a Sun's one) releases a fine suite of skinnable components (and ajax-ready, would be even better).

  I don't think Flash games vendors or Flash-based menu developers (the most prevalent Flash uses) will suddenly switch to JavaFX. So, some focus on enterprise developers who want a powerful platform with some fine interfaces (and have to compete with web developers with their css tricks), and don't have time to create a complete LaF suite, would be really great! :)

  Posted by: ronaldtm on January 07, 2009 at 09:12 AM

• As a Swing developer, I don't have a huge problem with Swing being relegated to legacy status. Sun can do what it wants and I agree that Java FX is probably a much better paradigm for building UIs (assuming it gets a set of widgets comparable to those in Swing, SwingX, etc).

  My biggest complaint is the almost total lack of Java interoperability. The fact that you can't embed a Java FX panel in an existing Swing app is crazy. What's more crazy is that some people seem surprised that people would want this capability. It seems like the most obvious transition path for getting all the existing Swing developers on board with Java FX. At this point, it feels like Sun is saying "throw away all that old yucky Swing code and rewrite it in Java FX". I hope I'm wrong because I'd love to use Java FX.

  Posted by: darevay on January 07, 2009 at 09:25 AM

• @darevay: Check http://blogs.sun.com/javafx/entry/how_to_use_javafx_in for embedding JavaFX inside Swing apps (I didn't evaluate this solution, don't know how good is it). I agree that the JavaFX/Swing integration should certainly be better, but it's not something easy to implement because JavaFX is a very different beast, it's got a completely independent rendering pipeline, I think it must hijack the EDT, etc. Hopefully, the limited integration that we see on v1.0 is just temporary, Sun should have this item as a priority for the next feature release.

  We can also remember that Swing can be kept alive and evolving by many other companies and groups that produce Swing components, LAFs, tools etc. If JavaFX doesn't make the expected success, the community can uphold Swing even in a worst-case scenario where Sun stubbornly keeps it frozen and invests only in a failed JavaFX. Having new Swing features bundled in the JRE and standardized by the JCP is nice, but not having that is not a disaster.

  Posted by: opinali on January 07, 2009 at 09:56 AM

• As a reality check it's quite thin on the *available* functionality - including design tools, mobile and ecosystem. This may or may not change in 2009, but until it does, a lot of people outside Sun will remain skeptical.

  Posted by: kirillcool on January 07, 2009 at 02:49 PM

• @kirillcool: This is a reasonable criticism (the objective of my post was just to deflect those I consider to be FUD). Yes, there are some pieces missing in Java FX's game. We must trust Sun to deliver a great Mobile implementation in March; to close feature gaps like poor support for traditional form-based UIs as fast as possible; to improve the tooling even faster, etc. I don't consider any of these challenges unreasonable, and it seems that Sun is set to spend at least another full year extremely busy with Java FX. For all these reasons, the current release is clearly material for early adopters, even though I consider its quality worthy of the 1.0-FCS tag.

  Posted by: opinali on January 07, 2009 at 03:16 PM

• It's only natural with all the JavaFX buzz flying around that Swing devs feel the need to learn the stuff. It didn't help when I head someone on a Javaposse episode state bluntly "If you know swing you need to learn JavaFX.". Thats what motivated me to look into it over the xmas break. Unfortunately as an eclipse user I discovered that there isn't really a usable plugin.

  I'm now faced with dilema - to get experience in an RIA technology I can either wait for a usuable plugin or I can switch IDE. If I'm going to do that then it makes sense to learn Flash and use Adobe's IDE because their runtime has a higher browser penetration .

  Sun needs to clue up and get some bodies on a plugin really damn fast. (Getting the Kenai.com one going would be a good start).

  FYI, I did a quick jobserve.com search for jobs in the UK. Eclipse: 140 jobs Netbeans: 7 jobs.

  Posted by: drstrangelug on January 08, 2009 at 12:54 AM

• @drstrangelug: The need for an Eclipse IDE is indeed essential. I'm comfortable with NetBeans, but I tend to be mostly a Eclipse user because most of my projects are for IBM shops and I'm forced (by client requirement, really!) to use the IBM Rational IDEs :-( at least, their latest versions are based on latest Eclipse cores.

  OTOH, and as you know, Eclipse's support for desktop development is null since the abandonment of the Visual Editor project (a major fiasco for the Eclipse Foundation's open source community). The lesson here is that IBM doesn't give a damn for Swing developers, and they won't support Java FX either (heck, they don't properly support their own SWT-based RCP platform). The MTJ project was another joke until they finally dumped all code in the sea and adopted EclipseMe, but it's still missing a visual GUI editor; so, I won't expect any significant (i.e. visual) support for Java FX to appear in Eclipse's mobile side either.

  So, yes Sun should better make sure that a good and free Java FX plugin is eventually available for Eclipse; otherwise the Eclipse-dominated market will have another reason to avoid or postpone Java FX's adoption.

  Posted by: opinali on January 08, 2009 at 03:54 AM

• In response to ronaldtm, Flex is open source, as for the other major competitor, well, its Mickeysoft.....what do you expect? ;)

  Posted by: mezmo on January 08, 2009 at 07:09 AM

• Sorry, but I'm going to have to call BS on the entire mobile platform section. Not because you point out the other platform's weaknesses (which are true), but because you write about the JavaFX 'answer' to these weaknesses in the past tense -- as if the platform already does these things today. That's just plain false. We cannot, and must not, make claims like these until Sun actually delivers the platform. Everything you claimes may well end up being true, but until they deliver on the promise, the above claims are just pie-in-the-sky grandstanding.

  Posted by: seanairt on January 08, 2009 at 07:10 AM

• @seanairt: I agree that we can only evaluate Java FX Mobile when its 1.0-FCS release is shipping in our own devices. OTOH, it's also not fair to call JFX Mobile "pie in the sky" since Sun made its beta SDK available a month ago - I tested that, admittedly not in deep and using the emulator, but it looks pretty close to completion. Sun is set to make the official announcement (and probably release a RC-quality SDK update) at the Mobile World Congress 2009 (www.mobileworldcongress.com), that's less than five weeks from today, with the real gold release in the following month. That's VERY different, for example, from Adobe+Intel's demo'ing an AIR Mobile prototype back in 2007 with some UMPC device (was that a fake demo? he he).

  Posted by: opinali on January 08, 2009 at 08:22 AM

• Clearing the fud? Sorry, but your whole piece is a piece of FUD. No facts, just fanboy ramblings.

  Posted by: ewin on January 08, 2009 at 11:17 AM

• @ewin: Well, your post is not exactly the most well-articulated, fact-heavy rebuttal that I've read. Anyway don't worry - keep tuned in this blog as I plan to catch up with "hard facts" and to produce some myself.

  Posted by: opinali on January 08, 2009 at 01:20 PM

• "I don't think the JFX/Swing competition is a major issue, but that's because I don't think Swing has a big potential to become substantially better - it's a decade-old legacy that wasn't designed for today's needs"

  Well same coud be said about nasty 2 decade old fashioned nasty HTML and still there are efforts on it by major companies.Lets call now AJAX -> Aberrant javascript -css - html spagetti mess !

  I think it's just a matter of attitute to put efforts on improving an API. Don't blame on its old design. how about SwingX nice JXTable, Highlighters, Datetime picker, miglayout, substance,flamingo components,Jasper Reports ? When will see any of it on javaFX ? I like javafx I did a memo game to test and its nice, but what I really need at job is some useful way of coding a DATABASE front end with ease ! that's impossible now with javaFX so, sorry but I will stay at least with my lovely old kid swing !

  Posted by: aleixmr on January 08, 2009 at 02:39 PM

• Swing took a long time before it had usable performance. Coding in it was difficult at best. The native L&F's still aren't there.

  JSF is a trainwreck of complexity for a web 1.0 result.

  I've already seen a ton of deployment issues w/the JFX samples I've seen here on java.net alone. You'll have to forgive me if i'm not overly excited about JFX while it's still in the hype stages.

  Posted by: dirtyqwerty on January 08, 2009 at 03:13 PM

• I'm with darevay. It seems totally obvious for JavaFX and Swing to inter-operate. I'm shocked, that their shocked, that some of us think integration is important. It seems like a total no brainer.

  Posted by: raytucson on January 08, 2009 at 03:53 PM

• @dirtyqwerty: There are indeed deployment issues, some of these are bugs, others just app blunders - e.g. many demos are self-signed when they wouldn't need any signature, so the user is presented with a nasty security dialog for no reason at all. And even though JDK 6u10 was released (and then 6u11), Sun is still working fast on the new JRE/JPI/JAWS - 6u12 is already in beta with more important enhancements, and I guess the massive number of new features in 6u10 will still need another couple updates to close any regressions and fine-tune stuff. Java FX 1.0 being even newer, I'm sure many of those deployment problems are just bugs or oversights that can be fixed soon. In the end, yes, the deployment story is not yet good enough for mass rollouts of big Java FX apps; another reason why I consider the platform in "early adopter stage" at this time.

  @raytucson: The Swing integration was actually better in the Preview release; they cut some stuff in v1.0 just because it wasn't good enough for launch - so it looks more like a matter of Sun's schedule/resources than a oversight. Anyway we need to wait more for this, but at least Sun is working on it (check http://blogs.sun.com/meetjeet/entry/javafx_the_road_ahead, item 5: "We will, however, also provide a better integration for existing Swing applications").

  Posted by: opinali on January 08, 2009 at 06:12 PM

• 
  funny, that legacy (non!) argument - from what I've seen so far FX is going back to even before Swing was born in many places: hard-coded sizes (called "declarative" for modernity) are a complete no-no - especially in times of devices with widely spread resolutions, no models, no components to speak of, no semantic events (haha, last time I saw a onMouseOver was way back in 90ies, VBA), no focus control, no support for clear separation of concerns. And that so much highlighted tool support isn't that great not even for Netbeans 6.5 (no refactoring?) once you look through the smoke.

  So I wouldn't loose more time on the FX/Swing debate until FX leaves its baby crip. Sure I'm strongly biased

  Jeanette

  Posted by: kleopatra on January 09, 2009 at 02:49 AM

• @kleopatra: You point some important missing pieces, indeed. Java FX is not completely void of layout managers, but I could surely make use of something more sophisticated than VBox&HBox, perhaps a JFX cousin of GroupLayout (and such extra LMs, if provided, can easily fit in the declarative model - indeed that's the ideal model for that stuff!). A set of "native" components is coming (JFX 1.5 in June); I don't know of plans for semantic events (DnD etc.) but it would be incredible if this is not planned. Today you can fill in all these gaps with extra code, but of course this is not what you expect for a productive, general-purpose RIA platform. The tooling is promised to be much improved also in time for JavaOne'09. That's the reason why Sun plans three feature releases (1.1, 1.5 and 2.0) for this year alone: yeah, there are those missing pieces and they'd better close them soon. IMO, these feature gaps are just that, they're not architecture or design issues. But the consequence is that right now you can only use JFX realistically for a narrower niche of applications than the general scope of RIA.

  Posted by: opinali on January 09, 2009 at 03:06 AM

• The tension between Swing and JFX appears to be in the respective target audience. As far as I can see JFX is targeted at designers or programmers that are heavy into animation and visual goodies. Programmers that want to implement useful datamonging applications (say, forms based app with a database backend ) appear to be second class targets (if they are targets at all). In fact, all JFX tutorials and samples I have seen solve problems that do not interest me or my customers. Sorry. And this, by the way, is also the reason why no Swing developer that I know will jump the FX bandwagon.
  

  Posted by: norb on January 09, 2009 at 03:28 AM

• The day Sun abandons Swing is the day I start to abandon Java. Yes, Swing has it's faults, but why not address those? It looks like garbage (still) in Gnome while Windows gets all the love. But it is incredibly powerful and there are reasons why I (and many others) favour Swing over SWT or other toolkits. If Sun starts pushing JFX over swing, it had better do everything swing can at the very least. If we have to abandon many years of custom component design, time spent learning the toolkit inside and out, and rebuild everything from scratch, it may as well be on a different platform altogether.

  Posted by: canistel on January 09, 2009 at 07:58 AM

• The beauty of the JavaFX architecture is that it provides you with the right mixture of abstraction layers. On the one hand it exposes some low level, and basic geometric 2D/3D shapes, and constructs as first class citizens of the language. On the other hand, it provides you with high level declarative language constructs, and tools to easily manipulate, and add control logic, and smarts to these basic geometric shapes. For instance, take a look at this:

  http://blogs.sun.com/chrisoliver/date/20090108

  Now some people might perceive this powerful ability to manipulate these basic geometric shapes as a step backward, I see it as empowering, and liberating from the tyranny of Swing's JComponent model where the rule is: We give you any shape you want as long as it is rectangular, and opaque.

  Posted by: mikeazzi on January 09, 2009 at 08:01 AM

• We've lost on the Swing front, but the real front is the Java front.
  I personally don't want to code in JavaFX. I love Java and I don't want/need another UI language on the JVM. So, all I'll look at when the release their new UI Toolkit and components is: can we use it in Java.

  If not, then a big open source organization coming with closures, properties and Java components using this toolkit and some binding (allowed by the property functionality), all that with a compiler in a NetBeans plugin will be tempting for a lot of people. I recall when I was so scared of a fork when Java got open sourced.

  Sun really needs to send us a message like "the new components can be used in Java and properties/binding are coming in Java 8, please be patient, we heard you."

  Olivier Allouch

  Posted by: nopjn on January 09, 2009 at 08:05 AM

• That was my point. If the past Java UI initiatives are any indication (Swing, JSF) it will be YEARS before JFX is competitive w/the flash and/or Silverlight of today. Those competitors aren't sitting still. By the time JFX actually gets to where it needs to be, it will likely be obsolete. Just like Swing and JSF.

  Every new Java UI initiative is touted as the next big thing, when in reality it's never been the case. Sun is behind the game and they know it. They don't have a product or portfolio so all we have right now promises of greatness.

  IMO, this is how mature JFX should have been when it was first announced however many years ago at JavaOne.

  Posted by: dirtyqwerty on January 09, 2009 at 08:39 AM

• @canistel: Sun is not going to abandon Swing, it received important improvements like Nimbus in 6u10 and will have new features like the Application Framework in Java SE 7. I just expect that the ratio of investment in new features will be reduced, in comparison to the previous situation of Swing as Sun's single offering for desktop GUIs. Swing will be like the Servlet API: it's still there, it's even getting new features every few years (check JSR-315), but it's certainly not the preferred API for modern, application-level web development... and it's not the focus of new offerings in third-party libraries and tools. But no one complains that Sun "abandoned" Servlets in favor of JSP, JSF, etc.

  Posted by: opinali on January 09, 2009 at 08:49 AM

• @kleopatra: Check Amy's blog (http://weblogs.java.net/blog/aim/archive/2009/01/layout_primer_f.html) for an authoritative check on Java FX's support for automatic layout management. The situation is, like I hinted before, just a feature gap soon to be closed, not lack of proper design.

  Posted by: opinali on January 10, 2009 at 06:37 AM

• Well some of the examples I've seen look good however as a Swing developer for many years I am less than impressed with the performance of the FX that I've seen so far. I have written similar glossy GUI's in Swing/2D that would smoke what I've seen in FX. Ok it maybe easier to code but once you have the basic re-useable code in place its fairly easy in Swing/2D.

  What I would really like to see is the ability to extend customer projects I'm working on with FX bits. For instance I'm working on mapping software so I think the FX screnegraph could be useful for showning and controlling features on the map but it doesn't look trivial to combine FX and Swing in anything other that simple fairly static Swing display environments. What happens when you are using layered panes, handling resizing ...... There is no way I could re-implement in FX because it would be so slow to be unusable and also appears to be a lot more memory hungry. One last thing the start up time seems to be fairly long as well.

  My 2p

  Posted by: swebb99 on January 15, 2009 at 05:35 AM

• @swebb99: I'm finishing some initial performance evaluation of JavaFX (I updated the JavaFX Balls benchmark to v1.0 and then tweaked it a bit), should post results in this blog soon, both good and bad findings. But in short, JFX's animation engine performs pretty strong overall, but I identified a couple bottlenecks that will require improvement.

  For your needs, a good solution could be just using the Scene Graph as an isolated API. That was previously available at https://scenegraph.dev.java.net/, but Sun has yet to update this project with the current version (post-JFX 1.0). I didn't try it, but my understanding is that the Scene Graph is a decoupled API that you can use just as easily with Swing or with some custom animation/game engine etc. I hope the media codecs also turn out to be sufficiently decoupled from JavaFX, so you can just "steal" a few jars / shared libs, put them in your Swing app's path, and use the media features, without being forced into JavaFX Script or the javafx.* frameworks. This would be great for the Java ecosystem as a whole. But we must wait a little longer for the full open source release of JavaFX (my crystal ball points to mid-February).

  I didn't notice, however, a significant footprint or startup issue. A quick experiment with the Bubblemark:

  - JavaFX: 48M Private Working Set, 86M Private Bytes, 344M Virtual Size; Average heap usage (OldGen) = 2,5M with zero activity.
  - Swing: 35M Private Working Set, 70M Private Bytes, 338M Virtual Size; Average heap usage (OldGen) = 2,6M with zero activity.

  The footprint is higher for the JFX app (+13M PWS). But notice that my version of JavaFX Balls has a control toolbar with a few Swing components (buttons and radiobuttons), so I'm actually paying the price for JavaFX and Swing combined (I could have written "pure" JavaFX controls, but I didn't care, and Sun is prepping a JFX component set). Unfortunately JavaFX will load 200+ classes from core Swing even in a program that makes no explicit use of Swing, I've already complained about that, I don't know if this dependency can be reduced or if it' can't be avoided due to JFX/Swing interop and reuse. Another problem is that JFX's runtime (~5Mb) does not benefit from CDS (Class Data Sharing), while Swing's does. These are all unfair disadvantages against JFX, but Jeet Kaul confirmed that Sun is working on "big changes" to address these problems, hinting specifically at the Jigsaw modularization project (that's unfortunately due to JDK 7, unless they backport).
  

  Posted by: opinali on January 15, 2009 at 06:36 AM

This work is licensed under a Creative Commons License.