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.
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 fxexperience.com.
- The new
SwingNodeclass enables developers to embed Swing content into JavaFX applications. See the
SwingNodejavadoc and Embedding Swing Content in JavaFX Applications.
- The new UI Controls include the
javafx.printpackage 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
PointLightsubclasses) , and
SceneAntialiasingAPI classes have been added to the JavaFX 3D Graphics library. The
CameraAPI class has also been updated in this release. See the corresponding class javadoc for
javafx.scene.SceneAntialiasing, and the Getting Started with JavaFX 3D Graphics document.
WebViewclass 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.cssjavadoc for more information.
- The new
ScheduledServiceclass 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