Would be really awesome if JavaFX could work together with GraalVM and Clojure. Then I'd be in "desktop application development" nirvana, when I can ship binaries to all platforms and build the application itself with cljfx (https://github.com/cljfx/cljfx).
Once every ~6 months for the last 2 years or something I've given it a try but there is always something broken or missing. Not sure what the status is right now.
I tried cljfx earlier this year for a prototype and was really satisfied with the developing experience. But I was also quite disappointed when I learned about the GraalVM incompatibility; it would have been a dream to have AOT and fast startup times.
Kotlin folks are working on something like that. There is multiplatform UI toolkit that targets native, android, java desktop, web and who knows what. I do not remember the name (Synergy, Fusion?, jetpack?)
Compose. It's the "new style" UI on Android. There, its full name is "jetpack compose" and it's a much bigger break from what came before than JavaFX vs Swing/AWT. Jetbrains are doing a port to desktop under the name of "compose desktop".
It does work with GraalVM (although the last time I did anything with that, I went through Gluon, which provides a bunch of wrappers around it). I have no idea if Clojure works with GraalVM, but if it does I guess the only missing piece is doing all the work the Graal & Gluon Maven/Gradle plugins do in cljfx? Plus the multi-minute build cycle which requires several GB of RAM, but that's a whole different kettle of fish.
GraalVM is really more like a very specialised JVM that can be used to spit out a native binary for any platform for which there exists a GraalVM version.
But in order to do that, it does some interesting things under the hood, and it doesn't play nicely with reflection by default (amongst other things). For some non-Java JVM languages that's a major problem since their compiler produces JVM byte code that relies heavily on reflection (Groovy is/was a great example of this). I'm unsure how much, if any, reflection Clojure relies on but that would be the most likely reason for it to struggle with GraalVM compatibility.
Well, the reason behind all that is that Graal has a closed-world assumption regarding classes - it has to know about every class file that will potentially get loaded at runtime.
SubstrateVM (which is what everyone here means when they say ‘GraalVM’) is not a compliant JVM, except for a get-out that just runs a normal JVM as a launcher.
Setting up the JavaFX development environment for anything post-JDK8 was incredibly difficult. I was recently tasked with creating an internal GUI application and re-visited JavaFX development after a few years' absence from the space.
I have to say, IntelliJ has come a long way. I was able to create a new JavaFX project from template and the magic green "Run" button worked out of the box. If you've previously been off-put by the difficulty in getting up and running with JavaFX, it's worth it to take another look since some of the improvements by IntelliJ. It feels a lot like the JDK8 days.
The amount of magic flags needed to get JavaFX working is ridiculous. I'm working on a Kotlin application with a JavaFX UI and I have to rely on Gradle to get it all working. Even then, when I wanted to get some wodgets from controlsfx working I had to add 14 new commandline options (various --add-opens options), none of which was properly documented anyhere.
How long can you keep the term 'next generation' on your homepage and not trigger ridicule? Given the project is over a decade old, you gotta wonder what it considers 'current generation'.
Very long, to the fraction of the audience that is maintaining something AWT/Swing. Considering the general shrinkage of the audience for java desktop UI development, that fraction has likely been growing ever since.
I've had an interest in using JavaFX multiple times for several projects over the years, it looks great, you get you use Java, and you can ship on all the platforms. I think the biggest problem I've had with it in the past is getting development up and running using a standard IDE like IntelliJ. Setting up JavaFX is confusing for beginners. There aren't a lot of great tutorials out there and the versions are especially confusing.
Which version of Java should I have installed? Which version of JavaFX should I have? How do I get them both installed and working nicely inside of my preferred development environment? I'm not saying it's very difficult, but there is a lack of easy material for beginners looking to start coding. Or at least there was the last time I tried to use it for a project.
I’ve seen a lot of movement in FX lately but lesser and lesser desktop apps coming out for Java specifically after electron apps picked up. Who here plans to use Java for their next consumer desktop app?
We've been using JavaFX for some internal tools, and the user base is generally fairly pleased. There are even libraries out there that handle automatic updates and the like. I would definitely continue to use JavaFX for trivial desktop applications that do one job and need to do it well.
For better or worse, Sun and Oracle never really pushed hard for standalone java based executables that you could install like a typical native app. And I think that stigma continues to stick to them even though bundling appears to be easier these days. Electrons only goal is to provide a path for native app deployment so many probably feel its a safer bet.
I'm currently writing a Java desktop app. I thought about using electron and others, but outside Qt, which seems like the "best framework", there isn't something without tradeoffs. Starting with JavaFX was quite simple (having a Java background helps). What I miss is the level documentation that you can typically find for Java.
Not strictly consumer, rather a niche space, but we're still shipping Swing based apps, and our customers neither know what the UI toolkit is, nor do they care.
So this makes me wonder: how common is desktop app development with Java these days? I imagine there is still a lot done for internal app, but is it still viable to ship Java apps to end users? How you handle JRE distribution in that case?
Anyway also wanna shout out Dear ImGui[0]. I've been using it recently to build an interactive UI to quite complicated networking code. So far it been great for manual testing and demos, and it's fairly low maintenance once running.
My biggest question today, since it's "java day" (jakarta, FX, and NetBeans stories today), is where do folks "talk" about this today.
Conversations, musings, etc.
SO is limited by their Q&A structure. Most of the mailing lists I've subscribed to are dead. I don't do Reddit, but even there /r/java doesn't quite seem right.
I just don't know which bar the java geeks hang out in nowadays.
I'd really like to just "talk" Java FX with some folks somewhere.
I'm not found about AWT, Swing and JavaFX. Including a UI-Toolkit within the base-library of a programming language seems like a mistake. It doesn't integrate well. It is not usable for other programming languages. And support for font-rendering, acceleration, HighDPI or Wayland is problematic.
I've to maintain a small Swing based application and I don't appreciate it.
Not directly, but there's several small (integration doesn't really take much) projects that make integrating CDI straightforward. The secret sauce is tying in to the FXML loader, then magic happens.
Once every ~6 months for the last 2 years or something I've given it a try but there is always something broken or missing. Not sure what the status is right now.