It has a very active community, nothing is dead when there are active users. It has been living as independent package for a long time https://openjfx.io
I wish Oracle did a better job for Java GUI, sigh. Java could be more lightweight than electronjs as a cross platform desktop GUI stack. Swing is the only one officially supported, but, it does not look that great on the screen.
I don't remember Java being any more lightweight than Electron. Both are super heavy, easily recognizable (because of there non-native nature and general subpar performance), have giant binaries/payloads. Especially Swing. Noone has ever complimented IntelliJ on its responsiveness... (IntelliJ is great nonetheless)
I just thought that people moved to Electron for cross-platform and to native otherwise. Java was not particularly fast nor native-looking on desktop. I’ve spent quite a few years in Swing, and am not sure it’s much better than Electron. But with GraalVM, maybe…
It really depends on the developers writing the application, but in my humble opinion Java and Swing are far better than Electron in terms of responsiveness to user interactions.
IntelliJ is 20yo old app, with lots of resources invested, they likely have many non-trivial optimizations implemented and do not represent vanilla java experience.
I made a somewhat trivial app in javafx, bellsoft JVM with native graalvm/javafx included and it was an ok experience. It definitely shows the community is small, but a lot of the key issues were solvable which makes me think a few larger communities putting love j to it could reply turn things around. Kinda like redhat dumping a ton of effort into python and is kits for redhat, etc.. the love really seemed to help that community in the times it was needed.
> Hmm, I thought that JavaFX is effectively dead, after it was removed from JDK
I remember reading that they were removing it from the JDK so it wasn't tied to Java release schedules, enabling them to have more frequent updates. Don't know how it worked though, but where I live I know, by reading job offers, that at least a couple of companies use it.
Ah... I used JavaFX for in-house tools a few years ago.
Now I'm on different company and mostly work on Android apps. Practically see zero demand for desktop apps nowadays. Well, perhaps for personal projects, then :)
This is impressive work, snappier than most of the "compile a rich Java GUI to js" systems out there, which can take minutes to start up -- an eternity on the web.
While I've used JavaFX on non-trivial projects, the momentum for UX definition seems to have swung towards HTML/CSS. To combine HTML/CSS layout with Java frontend logic, I have switched to Flavour ( https://flavour.sourceforge.io/ ) for all my new projects. (Disclaimer: while I didn't create Flavour, I'm now the maintainer.)
I did an analysis and selection of rich client platforms while at (ironically a retail FX/forex company) and Java FX was one of the last ones standing. They all seem to have fallen out popular fashion to web frameworks/Electron, native, and egads React Native. Good to see these resources all in one place.
Good timing. Just the other day, I was reading up on $current_year cross platform GUI solutions, like the back and forth discussions on the merit of React Native vs Ionic or Capacitor, or whether the "future is Flutter" or how Google may go all-in on Kotlin Multiplatform and abandon flutter. You know, the usual drama.
Then I remembered some years ago, in this similar situation, I decided to learn (invest time on) JavaFX when Qt, gtk, Xamarin and web tech were the alternatives.
Well, yesterday I googled, after all these years, if JavaFX apps can be run on Android devices (spoiler: no, or not in a usable way)
Now, in hindsight, I know that I put my egg on the wrong basket by focusing on Java and JavaFX. I was deluded on their write once run everywhere promise. I feel betrayed by Oracle due to their detaching of JavaFX from default JDK.
I think if I chose to focus on a web tech frontend framework (or even Qt) I'd been better off.
> I feel betrayed by Oracle due to their detaching of JavaFX from default JDK.
Why? Didn't removal of JFX from default JDK just meant that developers
are expected to bundle their own thin custom-built JREs alongside the
application? So that the applications will run on systems that don't
have a JRE installed, or their installed JRE is too old.
E.g. JetBrains distributes their own JRE with Idea, which contains
bundled JFX. Or, they did it in the past, not sure about today.
"just meant that developers are expected to bundle their own thin custom-built JREs alongside the application" can be significant initial setup work and overhead, and seemed more so back then. With Java 8, I shipped a combo Swing/JavaFX application, and built it once, and it ran everywhere. Now I have to figure out the module system and figure out how to ship it with platform-specific JREs? That's a lot more packaging overhead for a hobbyist project, or at least, that's what it felt like at the time.
After hearing (from Oracle) in the early 2010s about how JavaFX was the future of GUIs in Java, I can identify with the feeling of betrayal when it was unceremoniously removed from the JDK. If I'd known that was coming, I wouldn't have added JavaFX to my Swing application.
Nowadays we know that there are Bellsoft and Azul (is ZuluFX still a thing?) JVMs that still ship with JavaFX, but when Oracle made that announcement, we didn't know that, There were a couple years there where it looked like a significant refactor to externally linking OpenJFX, and shipping one-distro-per-system instead of one JAR, would be needed to move past Java 8. Now it's not so bad, I still target Java 8 as a minimum, but can point my program's users to the Liberica JDK and everything just runs.
With Gluon mobile you should be able to deploy to android.
> I feel betrayed by Oracle due to their detaching of JavaFX from default JDK.
I really find this to be extremely odd. It’s simple to add back as a dependency in your build file. Or just use a build like Azul’s which includes it in the runtime.
I have done a ton of Swing over the years, and also a 2.5D zoomable scene graph API called Piccolo2D [0], which was one of the inspirations for JavaFX (or so I heard at the time).
As far as your advice, I will take a look at swapping Batik out for EchoSVG, and also see how you tackled the user data directory issue in KeenWrite.
Great that JavaFX is not dead yet.
I still use it for hobby projects e.g. apps that communicate with Arduino or MIFARE card readers via serial ports.
Ad 2024 the framework is seriously behind any other commercial GUI be it WPF or Qt. I found the SceneBuilder to be highly unstable, crashing often several times during development.
The idea to use CSS for styling is not bad, but there is absolutely no autocomplete in IntelliJ Community for it. Makes writing it hard. There is a JavaFX plugin for Eclipse but it looks abandoned.
All in all it works when you need to put a simple GUI for your hobby project but I would not recommend it for any serious app.
As an aside for Clojure users, there is a nice “declarative, functional and extensible” wrapper for JavaFX called cljfx[1] that has been around for some years now. When I tried it last time to prototype a desktop app, I found it really pleasent and simple to work with, it felt like a more modern way to build JavaFX GUIs.
40 comments
[ 3.0 ms ] story [ 111 ms ] threadBut maybe now, that we have GraalVM Java will make a comeback to desktop?
what would be replacement?..
I remember reading that they were removing it from the JDK so it wasn't tied to Java release schedules, enabling them to have more frequent updates. Don't know how it worked though, but where I live I know, by reading job offers, that at least a couple of companies use it.
Now I'm on different company and mostly work on Android apps. Practically see zero demand for desktop apps nowadays. Well, perhaps for personal projects, then :)
While I've used JavaFX on non-trivial projects, the momentum for UX definition seems to have swung towards HTML/CSS. To combine HTML/CSS layout with Java frontend logic, I have switched to Flavour ( https://flavour.sourceforge.io/ ) for all my new projects. (Disclaimer: while I didn't create Flavour, I'm now the maintainer.)
Flavour lets you make fast-downloading single-page apps, like Wordii ( https://frequal.com/wordii/ ). It's easy to get started, there's a maven archetype and easy instructions at https://flavour.sourceforge.io/. Much more documentation is in the Flavour book: https://frequal.com/Flavour/book.html
Then I remembered some years ago, in this similar situation, I decided to learn (invest time on) JavaFX when Qt, gtk, Xamarin and web tech were the alternatives.
Well, yesterday I googled, after all these years, if JavaFX apps can be run on Android devices (spoiler: no, or not in a usable way)
Now, in hindsight, I know that I put my egg on the wrong basket by focusing on Java and JavaFX. I was deluded on their write once run everywhere promise. I feel betrayed by Oracle due to their detaching of JavaFX from default JDK.
I think if I chose to focus on a web tech frontend framework (or even Qt) I'd been better off.
Thanks for coming to my Ted Talk.
Why? Didn't removal of JFX from default JDK just meant that developers are expected to bundle their own thin custom-built JREs alongside the application? So that the applications will run on systems that don't have a JRE installed, or their installed JRE is too old.
E.g. JetBrains distributes their own JRE with Idea, which contains bundled JFX. Or, they did it in the past, not sure about today.
After hearing (from Oracle) in the early 2010s about how JavaFX was the future of GUIs in Java, I can identify with the feeling of betrayal when it was unceremoniously removed from the JDK. If I'd known that was coming, I wouldn't have added JavaFX to my Swing application.
Nowadays we know that there are Bellsoft and Azul (is ZuluFX still a thing?) JVMs that still ship with JavaFX, but when Oracle made that announcement, we didn't know that, There were a couple years there where it looked like a significant refactor to externally linking OpenJFX, and shipping one-distro-per-system instead of one JAR, would be needed to move past Java 8. Now it's not so bad, I still target Java 8 as a minimum, but can point my program's users to the Liberica JDK and everything just runs.
> I feel betrayed by Oracle due to their detaching of JavaFX from default JDK.
I really find this to be extremely odd. It’s simple to add back as a dependency in your build file. Or just use a build like Azul’s which includes it in the runtime.
* Building installer-free cross-platform binaries on a local Linux build machine requires an external packager[2].
* Good luck building an installer-free binary for CPU architectures that differ from the compiler's machine.
* Creating a Windows version will cost $ (to sign).
* Creating a macOS version will cost $ (to sign).
* WebView is a bloated beast that bundles JavaScript and exposes no API to set scrollbar positions.
* FlyingSaucer[3] is a lightweight alternative to WebView, but requires a SwingNode.
* SwingNode text rendering is blurry on Windows.
* SwingNodes issue GDK-3 warnings on Linux.
* Menu latching messes up cross-platform (Alt+Tab is a wrench).
* Modular applications are a pain. Migration has been poorly communicated, poorly documented, and poorly supported.
* RichTextFX has no way of changing the caret style in insert mode.
* PreferencesFX, and likely other FX libraries, has security issues.
* For MDI with dockable panes, take a look at tiwulfx-dock[4].
Java problems:
* "Write once, run anywhere" is no longer true.
* Apache Batik for rendering SVG images is buggy, EchoSVG[5] is better.
* Rendering math as SVG is hard[6].
* Cross-platform user data directory that complies with XDG, Windows, and macOS will take effort.
* Reliably locating executable programs across platforms is a chore.
Depending on your requirements, C++ and imgui may be a better choice.[7]
[1]: https://gitlab.com/DaveJarvis/KeenWrite
[2]: https://github.com/Reisz/warp/
[3]: https://github.com/flyingsaucerproject/flyingsaucer
[4]: https://github.com/panemu/tiwulfx-dock
[5]: https://github.com/css4j/echosvg
[6]: https://gitlab.com/DaveJarvis/KeenType
[7]: https://github.com/ocornut/imgui/issues/4400#issuecomment-89...
You fell trees with saws, not hammers.
I cannot imagine electronjs having the chops to implement KeenWrite.
https://keenwrite.com/screenshots.html
I have done a ton of Swing over the years, and also a 2.5D zoomable scene graph API called Piccolo2D [0], which was one of the inspirations for JavaFX (or so I heard at the time).
As far as your advice, I will take a look at swapping Batik out for EchoSVG, and also see how you tackled the user data directory issue in KeenWrite.
[0] - https://github.com/piccolo2d/piccolo2d.java
Ad 2024 the framework is seriously behind any other commercial GUI be it WPF or Qt. I found the SceneBuilder to be highly unstable, crashing often several times during development.
The idea to use CSS for styling is not bad, but there is absolutely no autocomplete in IntelliJ Community for it. Makes writing it hard. There is a JavaFX plugin for Eclipse but it looks abandoned.
All in all it works when you need to put a simple GUI for your hobby project but I would not recommend it for any serious app.
[1]: https://github.com/cljfx/cljfx