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.
What were the startup times like without AOT and how large/complex was your prototype?
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.
I know nothing about the Java ecosystem. Isn't Clojure supposed to be compatible with the JVM and everything that runs of top of it?
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.
Re:JavaFX 19
by chrisseaton on Wednesday September 14, 2022 @08:45AM
(#32836367)
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.
Clojure is compatible. GraalVM is not compatible.
You can definitely call JavaFX from Clojure. There's also the cljfx project that is "declarative and functional". :-)
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.