Why Swing? Why not JavaFX?
Published at 22:53 on 30 January 2020
I recently decided to finally take a serious crack at developing a GUI application.
My first choice was to make it a native Mac application, and write it in Swift. I soon was reminded, by fresh personal experience, of what I had discovered the last time I tried to code a native Mac application: that Macs are approximately as programmer hostile as they are user friendly. Documentation was patchy and incomplete. Interfaces were bizarre and counter-intuitive. Worse of all, things change radically from release to release of the OS, to the point that most of the documentation out there is basically useless, because it is for MacOS releases prior to Catalina.
I could have persevered, but it was clear that MacOS app development is a dark art that takes a lengthy and painful initiation process to cultivate. No thanks; I just want to get my app coded and finished. Would have been nice to have a native app that dovetailed as nicely as possible with the rest of the system, but being able to finish it in a timely manner takes priority.
I had in the past year ran across Kotlin, which struck me as a well-designed effort to modernize Java (or, alternately, Scala done right: a more modern language for the JVM that avoids the pitfall of creeping featurism that led Scala to be excessively complex). Java has long supported portable GUI application development, and since Kotlin is a JVM language, you can easily call any of the Java libraries from Kotlin. So Kotlin it was.
It didn’t take that much research to determine that the new and supposedly preferred way to code graphical user interfaces in Java was JavaFX. So I went to the JavaFX web site, downloaded JavaFX, and typed in the “Hello, World” example listed on that site.
It didn’t work. After double- and then triple-checking what I had done, I could see zero discrepancies between what I was doing and what the tutorial was telling me to do.
Noticing that the current release of JavaFX hadn’t been out all that long, I tried regressing to the previous version now on long-term support status. The code still didn’t work.
I tried posting a query on Reddit as to what I was doing wrong. Nobody had any idea.
I reported the bug via the project’s GitHub page. That prompted a curt, incomprehensible, acronym-laded response to file the bug report some other way (and my bug report on GitHub was perfunctorily closed).
Eventually, I got the example code to produce the output it should, by regressing to the version of JavaFX that was distributed with JDK 8. Then I started investigating how I’d code my program in JavaFX.
It quickly became apparent that one of the things I needed to do would probably involve a lot of work in JavaFX, but that there was a Swing UI component that did basically all I wanted, and that it was easy enough to embed Swing components in a JavaFX application. While doing that, I ran across yet another bug in JavaFX.
But why? I had already established that JavaFX is full of bugs, insufficiently documented, and has a development team whose attitude about quality is lacking. Now I learn I can’t even code it all the “new way” even if I desire to, because JavaFX is lacking in basic features as well.
Moreover, it didn’t take much research to uncover that Oracle (the single most important player in the Java development process) makes massive internal use of Swing, and has no plans to remove support for Swing anytime soon. In other words, Swing is definitely here to say; rumors of its deprecation have been greatly exaggerated.
So that’s what I used. Maybe, in a few years, if I have occasion to write another graphical user interface, I will investigate if JavaFX is any closer to being ready for the prime time than it currently it is.
I can tell that some of what JavaFX is trying to accomplish would be a real improvement. It’s a pity that the current state of that project is evidently so lacking in features and quality control, but there you have it.