JavaFX decoupled from Java SE 11

Three weeks ago, Oracle’s Donald Smith announced that JavaFX will be decoupled from Oracle’s own Java distributions starting with Java SE 11 (expected this fall). This is reflected in the updated Java Client Road Map which also notes that Swing and AWT will continue to be part of Java SE, “supported by Oracle through at least 2026.”

Immediate reactions on Twitter varied widely. There was wailing and gnashing of teeth that JavaFX has been left to die, but also enthusiasm that bug fixes and new features could be introduced more quickly and easily, assuming the contribution process is no longer controlled by Oracle.

What is happening?

First, it’s important to read closely what Oracle has actually said. From the Java Client Road Map:

Having open sourced JavaFX and related tools [through “OpenJFX” in 2011], Oracle is working with interested third parties to make it easier to build and maintain JavaFX as a separately distributable open-source module.

And from Donald Smith’s announcement post:

Moreover, with our focus on increasing the release cadence of OpenJDK, JavaFX needs to be able to move forward at a pace driven by the contributions from Oracle and others in the OpenJFX community.

So while Oracle certainly expects third parties to continue and increase their contributions, there’s no promise or threat (depending on your viewpoint) that it will completely cease to either contribute to or distribute JavaFX, at least in the near future.

However, Oracle no longer guarantees any support for JavaFX, starting with Java SE 11. Picking that version for the decoupling was no accident. In Oracle’s new semi-annual release scheme, Java SE 11 is the next release with long-term support, i.e. free public support for several years rather than six months. (The previous LTS release was Java SE 8.) In other words, Oracle reserves the option to stop supporting JavaFX at some point down the road.

Why decouple JavaFX?

Oracle’s reasons for splitting off JavaFX are not hard to guess, and even spelled out directly. Here’s a veiled hint from Donald Smith:

JavaFX has found an audience among developers and ISVs producing unique desktop applications and solutions for specific markets blending together multimedia, web and visualization technologies.

“Found an audience” for “unique” solutions in “specific” markets means in plain English that JavaFX is a niche API whose relatively limited appeal does not warrant inclusion in the hugely popular Java SE. The road map is quite clear on that point:

Over the last decade, the JavaFX technology has found its niche where it enjoys the support of a passionate developer community. At the same time, the magnitude of opportunities for cross-platform toolkits such as JavaFX in the market place has been eroded by the rise of “mobile first” and “web first” applications.

Here the term niche is used explicitly, along with the well-known fact that cross-platform UI development outside of HTML has been declining for a while. The popular 2015 article Should Oracle Spring Clean JavaFX? included some instructive Google Trends charts and other figures on that point. Searches for JavaFX did indeed overall rise from 2007 to late 2015 whereas those for Swing declined. But the rise of JavaFX was slow and uneven, the fall of Swing was precipitous, and both technologies were dwarfed by Java EE, Android, and Adobe Flash of all things (which also rapidly declined).

The limited appeal of JavaFX was likewise evident in the widespread indifference to Oracle’s decision. Various developer websites published a single news report each, and that was it. The one exception on JAXenter was written by Johan Vos of Gluon, a company that “has invested heavily in JavaFX”. Unsurprisingly he’s very upbeat about the stand-alone future of JavaFX.

There is one interesting point, though. Gluon has compiled download figures for JavaFX tools which indicate that this framework is finally picking up steam. Gluon says the lack of public visibility is because much JavaFX development consists of enterprises building industrial or internal applications under NDAs.

What should you do?

There’s no reason to panic if you are currently using JavaFX. It’s quite unlikely that Oracle will immediately cease sponsoring JavaFX with the release of Java SE 11. Besides, if Gluon is correct about big enterprises investing heavily in JavaFX there should be a pool of third parties able and willing to pick up the slack.

JavaFX is in my view not clearly above the level of popularity where it could be reasonably expected to survive on its own, but neither is it clearly below it. Much will depend on what Gluon calls the “hidden economy” of JavaFX.

Here’s a harder question: Should you pick JavaFX or Swing if you want to build a new Java desktop GUI right now? That used to be a no-brainer due to AWT/Swing lacking any high DPI capability, but as it happens that just changed in Java SE 9.

You’ll have to use JavaFX if you want its advanced graphical features, of course, or maybe run JavaFX on iOS and Android (Gluon offers that). For a simple typical business application, though, I’d be inclined to just stick with Swing for now until the situation becomes clearer. A larger ecosystem, guaranteed Oracle support, and distribution with Java SE are strong arguments.

Update: Jonathan Giles

Just today JavaFX veteran Jonathan Giles of FX Experience fame has published his own perspective on JavaFX. For several years he was working full-time on JavaFX at Sun and then Oracle, so he knows things from the inside. Here’s an interesting passage:

At the end of the day, my feeling is that JavaFX simply fell into this void – whilst there are some Oracle products using JavaFX, there wasn’t enough, and thus justification for ongoing investment became a tough sell, with investment waning over time. Every time we lost some engineers, I felt that surely, we couldn’t cut anymore – but I was all too frequently wrong.

My takeaway here is that Oracle nominally keeping JavaFX would not have been beneficial, as they were going to cut investment to the bones anyway. Better to take chances on the community than see JavaFX stagnate within Oracle, and eventually disappear.