JavaFX

» see openjfx.io as it lived, on the wayback machine

~ the obituary ~

i wrote java in university around 2005 to 2010. swing was already wheezing then. you could feel the toolkit losing the race against the browser, and every java desktop app shipped with that same beige metal look that made it obvious which one was the java app on your taskbar. javafx was sun's answer to that problem. an answer that arrived too late to matter.

javafx 1.0 went public on december 4 2008, the same year sun was already being circled by oracle. it shipped with its own scripting language called javafx script, a css-like styling system, and a media stack that was supposed to compete with flash. the developer reaction was muted. by 2011 oracle had killed the script language and rebooted the api as pure java for the 2.0 release. nobody who had written a javafx 1.x app was happy about it.

javafx 2 actually worked. scene graph, fxml, properties, css styling, hardware-accelerated rendering, the whole modern desktop gui kit. for a brief window around 2014 there was a reasonable case that javafx would replace swing in the enterprise. then electron arrived. slack got built in it, github desktop got built in it, and the conversation about cross-platform desktop guis migrated to a chromium engine running html. oracle stopped pushing javafx around the same time.

the actual death certificate is dated september 25 2018, when jdk 11 shipped and javafx was no longer in the box. you could still install it as openjfx from gluon, but a desktop framework that requires a separate download to even start has already lost. enterprise java moved to spring boot on the server, and the client side became the browser. javafx kept existing without anyone noticing.

~ the case file ~

~ how it landed ~

the original javafx 1.0 release was a category-defining mistake. sun shipped a new language (javafx script) on top of a new framework on top of the jvm, and asked enterprise java developers to learn all three at once. the result was that almost nobody wrote production javafx 1.x code, the script language got killed in 2011, and javafx 2.0 quietly arrived as pure java with a completely incompatible api.

this is the polite way of saying that oracle threw away the entire 1.x effort and pretended it had never happened.

~ the long tail ~

openjfx still gets releases. gluon maintains it as a separately distributable module. there are a handful of large enterprise apps that still ship on javafx because rewriting them is more expensive than keeping a working build. the netbeans ide had a long javafx tooling story. intellij never really did.

most new desktop projects that need cross-platform now reach for electron or tauri. java client work that needs to look modern usually ends up as a web frontend talking to a spring boot backend, which is the same architecture as a web app that happens to be served from a jar.

~ the inheritance ~

the fxml file format is the most interesting thing javafx left behind. it was the closest the java world got to a declarative gui markup that did not pretend the html dom did not exist. android xml layouts borrowed the same idea slightly differently. swiftui and jetpack compose later took the declarative gui pattern fully back to code, and the markup-based gui era ended.

javafx the brand is dead. javafx the rendering engine still runs under your eclipse jee plugin somewhere, doing the work, getting no credit.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »