JavaFX: Why it matters even more with Java 8

I have previously blogged about the annoying prevalence of FUD surrounding JavaFX and unfortunately this article by Paul Krill titled “Sorry, JavaFX — Java 8 won’t help you matter” published on InfoWorld a couple of weeks or so ago is just another example (and a particularly bad one at that).

Given the number of glaring technical anomalies in the article, I am still in two minds as to whether it was just another anti-JavaFX trolling attempt or if the author simply just didn’t do their research.  It’s also possible that it was just a slightly late April Fools Joke given that it was published on April 2!

Either way, I do get angry when a supposedly reputable site like InfoWorld publishes such nonsense-ridden guff about a technology that I personally have invested a significant amount of time and effort into.

The article doesn’t start well with the opening salvo:

“The rich client technology has devotees, but analysts doubt its viability as the RIA space loses ground to mobile apps”

So what does JavaFX have to do with the “RIA space”, whatever that might be?  Admittedly the Wikipedia article on RIAs doesn’t help here but JavaFX is not a technology that is predominantly designed to run inside a web browser and is therefore not a RIA technology.  The concept of RIA is now almost entirely related to HTML5 as the previous contenders for plugin-based alternatives (namely Flash and Silverlight) gradually disappear into obscurity.

Krill declares that JavaFX is apparently both a “rich client technology” and a RIA (which in my dictionary is not possible) and that (whichever one it is) it is losing ground to mobile apps.  Well, this rather confusing statement highlights the real problem with JavaFX, namely that many in the community don’t really understand what it is or what it can be used for.

JavaFX is a technology for building applications with a Graphical User Interface (GUI) using JVM-based languages and doesn’t really care where or how that application is deployed or launched.  Currently it runs on all the major desktop operating systems such as Windows, MacOS & Linux as well as on embedded platforms such as Raspberry Pi and BeagleBoard and also runs on the mobile operating systems iOS and Android (although there is no official release for mobile platforms yet).

The support for JavaFX on mobiles and tablets is growing rapidly through technologies such as RoboVM for iOS and by utilising Dalvik itself for Android.  The RoboVM website states “RoboVM translates Java bytecode into native ARM or x86 code” and the Android port utilises the Dalvik classes themselves (remembering that Android already uses Java).  The point is that with both of these solutions, the actual applications running on mobile devices are just as native as any other apps developed for those platforms so it is just plain silly to claim that JavaFX is “losing ground to mobile apps”.  The beauty though of course is that you can take your JavaFX code base and then run applications derived from it on desktop, embedded and mobile platforms.

The article goes on to quote John Rymer of Forrester Research as saying:

“I’m afraid JavaFX is too little, too late. JavaFX certainly didn’t accomplish Sun’s goal for it, which was to make Java the top environment for Web client and mobile development.”

Well, there’s actually no evidence to support the outlandish claim that JavaFX is “too little, too late” because all of the platforms that JavaFX either currently runs on or will soon run on are still very relevant and I am guessing that applications running on those platforms together comprise about 99% of all existing software!  And what it is this “Web client” that he speaks of?  Whatever that is, I am pretty sure that Oracle (who purchased Sun Microsystems) have zero plans for JavaFX to be the “top environment” for it.  Web client equals HTML (4 & 5) and that is it.  Period.

The next ludicrous remark in the article is:

“Like Adobe Flash and Microsoft Silverlight, JavaFX has been pushed to the background.”

WTF? This is another of the major misconceptions about JavaFX, that it is just a competitor for Flash or Silverlight.  Well, JavaFX is not and never was just a competitor for these now declining technologies.  It is an entirely different class of product and given that it is not reliant on being deployed to run inside a browser, HTML5 poses absolutely no threat to its future relevance (see here for a previous article of mine about this).  JavaFX is not being “pushed to the background”; it is in fact growing and growing very rapidly.  It is true however that both Flash and Silverlight are on the inevitable path to oblivion.  Updating Flash on my Ubuntu machine this morning for example gave me a message to say that Flash 11.2 on Linux is the last version to be release by Adobe.  I didn’t get any such messages about JavaFX when I upgraded to Java 8!

The article then quotes another “luminary” in Michael Cote of 451 Research who further discredits the message with the quote:

“I think the days of the RIA are long gone and have evolved into what we call mobile and tablets. HTML5, Android, and, of course, iOS handily won.”

This statement by itself would have perfectly acceptable had he not prefaced it with the declaration that he “sees JavaFX as a fading rich Internet application technology”.  Given that I have already pointed-out that JavaFX apps on mobiles and tablets are true native apps for those platforms, the implied negative connotations of this statement regarding JavaFX can be disregarded completely.

Krill himself then trumps the stupidity of all the previous claims in the article with this doozy:

“Oracle has demonstrated JavaFX on Android and iOS, though the Java runtime itself is not permitted on iOS devices.”

The problems with this one are twofold.  First, as explained, the Java runtime does not need to run on these devices for JavaFX apps to be deployed there.  Secondly, there is actually no reason in 2014 why the Java runtime would not be permitted to run on iOS devices.  The actual limitation is that Just-In-Time (JIT) compilation is not permitted on iOS which is a very important distinction.

Anyway, even if the reader of the article were able to distinguish FUD from fact, perhaps the main deficiency in an article with “Java 8” in the title is that it almost never mentions this latest and extremely significant update of the Java language and the improvements and enhancements in the version of JavaFX that is built-in to Java 8.  There is an absolute plethora of articles about the major and very important changes in Java 8 itself such as lambda expressions, streams, default methods in interfaces, the new date/time API and Nashorn (the high performance JVM-based JavaScript engine) and JavaFX has been updated to make use of many of these new features.

As for the new features of JavaFX 8 itself, Oracle’s page does a good job of describing them as:

  • The new Modena theme has been implemented in this release. For more information, see the blog at
  • The new SwingNode class enables developers to embed Swing content into JavaFX applications. See the SwingNode javadoc and Embedding Swing Content in JavaFX Applications.
  • The new UI Controls include the DatePicker and the TreeTableView controls.
  • The javafx.print package provides the public classes for the JavaFX Printing API. See the javadoc for more information.
  • The 3D Graphics features now include 3D shapes, camera, lights, subscene, material, picking, and antialiasing. The new Shape3D (Box, Cylinder, MeshView, and Sphere subclasses), SubScene, Material, PickResult, LightBase (AmbientLight and PointLight subclasses) , and SceneAntialiasing API classes have been added to the JavaFX 3D Graphics library. The Camera API class has also been updated in this release. See the corresponding class javadoc for javafx.scene.shape.Shape3D, javafx.scene.SubScene, javafx.scene.paint.Material, javafx.scene.input.PickResult, javafx.scene.SceneAntialiasing, and the Getting Started with JavaFX 3D Graphics document.
  • The WebView class provides new features and improvements. Review Supported Features of HTML5 for more information about additional HTML5 features including Web Sockets, Web Workers, and Web Fonts.
  • Enhanced text support including bi-directional text and complex text scripts such as Thai and Hindi in controls, and multi-line, multi-style text in text nodes.
  • Support for Hi-DPI displays has been added in this release.
  • The CSS Styleable* classes became public API. See the javafx.css javadoc for more information.
  • The new ScheduledService class allows to automatically restart the service.
  • JavaFX is now available for ARM platforms. JDK for ARM includes the base, graphics and controls components of JavaFX.

As you can see, it is very clear that both Java 8 and JavaFX 8 are major releases and that to say JavaFX is either “too little, too late” or “declining” is patently false.

On the contrary, JavaFX is growing and growing rapidly and has the very real potential to become the best toolkit for developing GUI applications and apps on a vast array of platforms from desktops and embedded to mobiles and tablets.

Since JavaFX 2, JavaFX has always mattered and now with Java 8, JavaFX most definitely matters even more!

Just my 2 bits


About Lucan1d

Co-founder of Bembrick Software Labs in Sydney, Australia, Felix is Lead Developer and CEO of this small, emerging start-up. Qualified with degrees in Computer Science & Zoology, Felix's other skills include musical composition, piano playing and singing (a work in progress). He loves cats, has a fascination for beetles (and most creepy crawlies) and is Christian from the Uniting Church.

Posted on April 21, 2014, in JavaFX and tagged , , , , , , . Bookmark the permalink. 32 Comments.

  1. Thank you for writing this. I have just started to teach myself JavaFX for a new project at work and was disheartened to read the same Infoworld article as I was just getting into JavaFX. It seems like a very strong technology and I look forward to learning more about it.

  2. I was around for most of the early lifetime of JavaFX – when it was still called F3 (and when it still had a scripting language), the guy who created it as his weekend project asked me to help write a plugin for NetBeans for it. I thought it was cool and passed pointed some other folks at it, and it started to get some momentum.

    At some point around 2005/6, there was a push to seriously invest in it, and it got an actual team to work on it. The vision there was to “show leadership” to all the vendors building J2ME phones and be the Next Big Thing. The practical result of that was that everything that had already been made available was deprecated while that team did their top-secret thing…and did it…and did it…and…Android happened. The folks working on JavaFX was so paranoid about getting it perfect before releasing anything that they might have to keep compatibility with that they went completely dark, and into that vacuum stepped Google, and J2ME was over.

    Since then, it’s been kind of a solution searching for a problem, and the last round of positioning it went through was as a Flash/Silverlight alternative, so people probably still have that stuck in their brains.

    I wouldn’t put a lot of stock in “analyst” opinions. I remember doing a tour of analysts at a bunch of places in New York, and talking to a guy whose literal *job* was to cover tools. He was all hot to trot about chat programs in IDEs. I had refactoring to show him – back when that was change-the-world change-your-life never-done-before stuff. Even a kindergarten explanation (“imagine you were writing a novel set in Los Angeles, and you decided to set it in New York instead, and your word processor could not only replace the city name but automatically replace names of streets and restaurants so that even a New Yorker would think that’s what you were planning the whole time”) did not get through. But instant messaging? Woo hoo. The analyst game is this: You pay a firm buckets of money for research, and they’ll say nice things about whatever you tell them to. They’re the mafia. So all the article being reacted to here says is that nobody’s paying these analysts to shower love on JavaFX. Period.

    JavaFX is pretty nice – and browsers and everything else are written using desktop GUI toolkits – they’re not going to cease to exist and it’ll be browsers all the way down. And most desktop toolkits are locked into an archaic design of boxes within boxes, which turns out to be problematic for anything involving animation or effects that want to paint outside a component’s box – older toolkits conflate the notion of logical containment with painting logic, and that proved to be a mistake. The world needs toolkits that don’t make that mistake, and there will be future generations of desktop applications.

    That said, I think any toolkit worth its salt needs to enforce things like making doing disk or network I/O in the event loop physically impossible (you could do it with a SecurityManager in Java, though that’s expensive) – or people will just create a new generation of software with the same old bugs.

  3. Thanks for your comments Tim.

    It’s not so much that *I* put a lot of stock in analysts opinions; I am concerned that *others* do and that when those opinions are so far off the mark (as with the original article) and lead people to avoid JavaFX, it is a big problem for us all.

    I am interested in your comments about the architecture of desktop/GUI toolkits and the remark that “older toolkits conflate the notion of logical containment with painting logic, and that proved to be a mistake”.

    Are you referring to Swing as such a toolkit? Personally, I think the power that the developer had with the paintComponent() method (immediate mode) is actually something I miss in JavaFX and is only really available in the Canvas control.

    I believe that a modern GUI toolkit has to harness the power of both a scene graph (for “static” objects) and immediate mode to best visualise content and animations and not just in a “special” one-off node like Canvas.

    I do disagree though with your comments about enforcing restrictions on the kind of work that can be done within the event loop because (as you hint at) it would be expensive and also because it’s pretty much “JavaFX 101” or “Swing 101” to know how to exclude long-running tasks from this thread. I really don’t think that this particular opening to introduce performance issues into your application is one of the Top 10 most significant failures of a toolkit…

    • Yes, I’m referring to Swing as such a toolkit. Compare it with, say, Visual Library from NetBeans – the reason you can do fancy animated stuff there, but it’s painful to the point of not being worth it in Swing (yes, there is the glass pane, and good luck not leaving paint-turds on components below it) is that it’s built around the observation that having a z-order is normal, not exceptional, and that revalidate-this-component-when-you-revalidate-that-one should not be tied to this-component-lives-insides-the-bounds-of-that. Which is the same observation that lets cool animations be done with CSS: this-owns-that does not mean this-contains-that.

      Re I/O restrictions: I worked full-time for 11 years on a framework that had doing at least some I/O in the event thread baked so deep in its architecture it could not be ripped out (I ripped out as much as I could, though). And in that time, probably 80% of the performance issues I saw could be traced directly to I/O in the event thread. I’d love to believe that it’s coding 101 not to do that, but there is always a new generation of developers who were taught “this is the way you read a file” and they’ll go and do it, not think about what thread they’re on, and it will look like it works, and that will be it – until that code is deployed somewhere with 4000 users whose home directories are on network drives and, kaboom. My experience is that, if the wrong thing is the path of least resistance, then unless a loud buzzer goes off, preferably with electric shocks, whenever they do it, it’s exactly what they will do. It’s simple enough to create a callback-based API for I/O that feels almost synchronous to use and avoids the problem – so why not do it?

      Re analysts, yeah, I walked out of IDE-chat-guy’s office thinking, crap, these are the guys who rate our stock.

  4. Hi Tim,

    On IO. I think built on Netty solves some if not all of those concerns.

    Any thoughts.


  5. Vertx solves the problem for network I/O – in fact I’ve written a framework similar to it here – – but in gui applications file I/O is usually the culprit, and particularly network filesystems are in issue.

  6. Nice to see. I think the world is finally realizing that threads make no sense as a model for doing I/O – it’s a leftover from the days when your computer was only running one program and your program couldn’t possibly want to do anything but wait on I/O. Ironically, async, being basically interrupt-driven, is much more like what we did in the bad old days of assembly language and bare-metal hardware access – which is still how that works for good reason.

    What gets lost in the Java world of Giant Enterprise Frameworks is that unless your whole stack is async, you’ve accomplished nothing – asynchronously calling a servlet that’s going to block on database I/O misses the entire point. Which is why I wrote Acteur – get some of NodeJS’s programming model for Java.

    Now I think we’ve thoroughly hijacked Felix’ comments section🙂

  7. Well, admittedly it’s gone a little left of field wrt JavaFX but it’s great to see this post generate so much interest and commentary from such well respected people.

    Back to your comments Tim about the path of least resistance, I am sure it must have been a massive PITA to try to remove such heavily embedded threading nasties but I am in the position with my own team whereby we all know of these pitfalls and just naturally code around them. Sure, if there were some massively inexpensive way of totally preventing sloppy coders breaking stuff I’d support it but then again I wouldn’t hire sloppy coders in the first place.

    Basically I guess what I am saying that out of all the issues I would like to see addressed in JavaFX, this particular one is way, way down the list of priorities…

    Anyway, keep up the comments guys!

  8. Re the I/O thing, the thing to remember is that if your reaction is “Oh, I know better than to do that” then you are not the target audience of something that prohibits it🙂

  9. Hi, very good informational post.
    I’m investigating on JavaFX 8. Would you mind suggesting me a good book, site, tutorial, etc… that you have found very good?
    Thanks bye

  10. But actually, JavaFX doesn’t mean anything for most people, because most people can not launch *.jar application and some *.exe reason is simple SECURITY. (exe and jar is terrible for windows, They don’t have App per Sandbox architecture) Major web browsers really care launch Java plug-ins, Display warning message very hardly. Also Oracle decide most Applets doesn’t run in default JRE settings. If app developer pay a few hundred dollars to CA and signing jar and users are a few warning dialog passed to barely launch Applet. (ewww)

    Who launch JavaFX app? No ecosystem in JavaFX world. If Oracle decide start JavaFX app store and strong Sandbox security completed to probably a little bit chance for new client side Java ecosystem, but Oracle doesn’t do it probably.

    • JavaFX is not just applets; desktop applications written in Java have been around since the mid-90s.

      • Desktop application is basically BROKEN. Because client side security is TERRIBLE. So many malwares, Windows still doesn’t have consumer clear sandbox. Linux desktop app should create user per one apps, and In OSX, use New sandbox APIs but most app still doesn’t implementation. Todays App definition HTML5 or iOS or Android, others are NOT APP.

    • With Java 7 update 6 or late it is possible to lunch *.jar file with the jre only and you can make native packaging easily and lunch *.exe. You can make it using javafxpackager or ant script. Everything are provided with Java SE.

  11. @narucy – I really don’t understand what you are talking about. Are you saying that no one should use Windows, Linux or MacOS because “Desktop application is basically BROKEN”? These operating systems will be around for a long, long time and they will have millions of apps/applications running on them just like they do today. JavaFX apps/applications run very well on those systems too and will continue to grow in that sector.

    And what does this mean: “Todays App definitions HTML5 or iOS or Android, others are NOT APP”? I really have no idea what you are talking about. Can you please let us all know what your definitions are for “app” and “application”?

    Besides, if you actually read the article above you will learn that JavaFX can run on both iOS and Android and that support for these platforms is set to grow significantly over the next couple of years.

    And as far as I am concerned, HTML5 makes web sites, not “apps”.

    • Enterprise specialized application is probably okay, Order received developer company doesn’t implements Malware for customer probably.

      But, PC export teach how to use PC to beginner, First important lesson is `Don’t touch .exe file’ Malware is very scary and powerful. Some random people says `Hey We provide excellent app, please execute this jar it (or, exe, msi)’ How to customer try do it? No market no ecosystem todays situation.

      • So we should all stop buying and installing software on our Windows, Linux and MacOS machines because of the threat of malware? Please tell me if that’s *really* what you are suggesting. Java/JavaFX applications are no different from any other in that sense so I am totally oblivious to the actual point you are trying to make!

        If you are unable to somehow start making sense then I fear my Troll Radar will start sounding very loudly…

  12. I’m agree with this article. I also read the infoworld article and I’m not agree with it.

    I like JavaFX and I’m trying to integrate it in new and old maintaning projects.

    Only one thing I miss in JFX: A pure JFX Docking Framework.


  13. I hate to ask such a newb question, but …. I am looking for an explanation of when I should use JavaFX and when I should use swing (assuming that they are not meant to be used together). Would it be appropriate to use JavaFX to write a simple (single frame) application? Or would that be like swatting a fly with a sledge hammer? Is there any reason that I should use Swing instead of JavaFX beyond the fact that my customers would need at least OS7 to run it?

    Also, the original author talked about JavaFX deployment. As I understand it JavaFX is designed to be used inside a Java application. Does a user need anything beyond the JRE to run a JavaFX program? Is JavaFX a part of Java? or an extension like Swing?

    • Sorry to take so long to approve your post and replying…

      Well, Swing really is “old news” now and should be avoided unless absolutely necessary. Such cases are when you are maintaining an existing Swing application, when your staff only know Swing and don’t have the resources to learn JavaFX or when you have to use existing 3rd-party libraries that are written in Swing.

      Having said that, you can use JavaFX inside a Swing application by using the JFXPanel which basically allows you to embed JavaFX controls with a Swing application.

      Other that that, I would highly recommend avoiding Swing entirely and focusing on JavaFX. It would certainly be appropriate to use JavaFX for a simple application or any sized application for that matter.

      As for where JavaFX sits withing the Java ecosystem, it’s just a standard part of the Java SE JDK now so you don’t need anything other installing Java itself to run it. If you install Java, you have installed JavaFX.

      I hope this has answered yor question and let me know if anything is not clear.


  14. Excellent post. I certainly love this site.
    Contiinue the good work!

  15. Oracle still heavily advocates the browser plugin and web start.
    At times when support for that is removed from chrome and coming with a big warning in Firefox, it does feel anachronistic, and the tie to Flash and Silverlight is implied by oracle themselves.

    Just go to the Oracle JavaFX pages. You don’t get a screenshot or capture of the capabilities there, only a disfunctional applet or webstart thing. It does feel like 1999.

    • Oracle does not still heavily advocate the browser plugin or WebStart by any means whatsoever and are actually trying as hard as possible to distance themselves from them as they are the 99% source of all Java-related security issues. My advice to *everyone* is to not use Java inside any browser at all and if you have no applications that use Java that run on your desktop then don’t even install Java. Sounds harsh, but Java is really just for server-side technologies where it is the absolute “king” and for developing new desktop GUI applications using JavaFX or maintaining older ones with Swing.

      Many will obviously disagree with this statement but it is the harsh reality given that there is *still* no official release of JavaFX on iOS and Android (and probably never will be) and in the just the last couple of weeks the newest builds of Java 8 have removed support for ARM (which basically means no more embedded support).

      Your comments about Oracle’s own JavaFX pages are spot-on and maybe now you know why. Their Ensemble application is basically a collection of controls, effects and animations in their most basic and least impressive form. As a catalogue of what is available in JavaFX it may be adequate but what they need is something to showcase exactly what JavaFX is capable of with its most advanced features and power.

      There is no such application although I personally am working on something which will hopefully fill this enormous gap.

  16. Oh, and on Linux, JavaFX is NOT INCLUDED. If available at all, openJFX comes as an extra package to install. I’m also nit sure about the performance then… often Oracle withholds some optimizations on Java. For example OpenJDK on a raspberry pi is interpreter only, and the performance thus is disastrous. More negative press for Java.

    • (It’s included in the Oracle download, but nobody uses that. Everybody uses OpenJDK which gets automatic security updates by the Linux distribution.)

    • Java or JavaFX on Raspberry Pi is nothing more than a novelty, just as the device is itself. The fact that Oracle thought it was more important to produce an official JavaFX port for this device rather than the ones that almost everyone on Earth carries around in their pocket every day is indeed perplexing and people can make up their own minds about that!

  1. Pingback: Java desktop links of the week, April 28 « Jonathan Giles

  2. Pingback: Java 8 개선 사항 관련 글 모음 — 생각하고 나누고 공감하기…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: