Home to Anything JavaFX Related(jfx-central.com)
jfx-central.com
Home to Anything JavaFX Related
https://www.jfx-central.com/
40 comments
I worked on the original JavaFX launch when I was at Sun. It was a really nice toolkit to work with. I’m glad to see it still being used.
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.
Very cool! Can you share any interesting story related to the adoption of Swing v JavaFX?
Hmm, I thought that JavaFX is effectively dead, after it was removed from JDK. Haven’t seen any app made with it for ages.
But maybe now, that we have GraalVM Java will make a comeback to desktop?
But maybe now, that we have GraalVM Java will make a comeback to desktop?
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 have a JavaFX app in production that ships 40mb binaries, which includes the JRE, and can run with a 50mb heap, and I haven't optimized it yet.
You can try out the desktop version of JFXCentral via this installer https://downloads.hydraulic.dev/jfxcentral2/download.html
> 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.
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.
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.
> I thought that JavaFX is effectively dead
what would be replacement?..
what would be replacement?..
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.
Java is unbeatable for "enterprise logic" though..
the primary java app I use is InteliJ suite and it seems as responsive/fast as any other app I use. Are they doing anything particularly unique?
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.
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 :)
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 :)
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.
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.
Lots of serious apps written in JavaFX can be found here: https://www.jfx-central.com/showcases
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.
[1]: https://github.com/cljfx/cljfx
[1]: https://github.com/cljfx/cljfx
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.
Thanks for coming to my Ted Talk.
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.
> 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.
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.
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.
You mean the Liberica JRE? Or is the JDK really needed to just run a .jar using JavaFX?
Azul has an OpenJdk build with FX already in it as well.
[deleted]
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 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.
Gluon adds a nag screen to Android deployments, unless you become a paying customer. And indeed, most vendors don't seem to support Android at all...
A few JavaFX issues I've encountered while writing KeenWrite[1], my FOSS text editor based heavily on JavaFX:
* 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...
* 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...
Thank you for writing up your experience!
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
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
so, electronjs still rules
> so, electronjs still rules
You fell trees with saws, not hammers.
I cannot imagine electronjs having the chops to implement KeenWrite.
https://keenwrite.com/screenshots.html
You fell trees with saws, not hammers.
I cannot imagine electronjs having the chops to implement KeenWrite.
https://keenwrite.com/screenshots.html
wonder why it can't, electronjs had made a long list of impressive desktop GUIs. keenwrite seems feasible to me
[deleted]
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