JavaFX 19 | Hacker News Reader

JavaFX 19

openjfx.io

85 pointsobdev49 comments

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 know nothing about the Java ecosystem. Isn't Clojure supposed to be compatible with the JVM and everything that runs of top of it?

Clojure is compatible. GraalVM is not compatible.

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.

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.

You can definitely call JavaFX from Clojure. There's also the cljfx project that is "declarative and functional". :-)

https://github.com/cljfx/cljfx

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?)

https://www.jetbrains.com/lp/compose-mpp/

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".

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.

Unfortunately the "magic green >>Build<<" button (at least for JDK11+ projects) is still missing :( Check: https://youtrack.jetbrains.com/issue/IDEA-20072

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.

I don't think it's difficult at all. Not today, certainly.

With a maven project it's a single dependency: org.openjfx:javafx-controls:18.0.1

And a simple plugin (org.openjfx:javafx-maven-plugin:0.0.5? (I think)), https://github.com/openjfx/javafx-maven-plugin has a quick start.

Then: mvn clean javafx:run

No need to tweak your JVM install, the maven downloads everything you need, including the platform binaries.

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.

in that respect, everything's 'next gen'...

Until it becomes “modern”

And then, "classic".

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.

> you can ship on all the platforms

Except Linux/Wayland for now...

https://youtrack.jetbrains.com/issue/JBR-3206

https://wiki.openjdk.org/display/wakefield

That's about Swing/AWT. JavaFX is a different beast ("next gen" replacement) and doesn't even have a ticket open for Wayland as far as I can tell :)

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.

Well, Qt’s tradeoff is that it is C++ and python-only.

https://tealpod.com/compressor/ for Mac OS is made with JavaFX. Windows version is developed on .NET MFC.

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.

Found release notes: https://gluonhq.com/products/javafx/openjfx-19-release-notes...

Mostly bugfixes.

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.

[0] https://github.com/SpaiR/imgui-java

I think you're right, it's mostly internal tools these days. Like a lot of Java stuff, it's the dark matter of the software world.

You can bundle the JRE with the app using https://docs.oracle.com/javase/9/tools/jlink.htm and use https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... to create distributions for the main platforms.

There is not even a JRE anymore, you are supposed to bundle the JDK’s relevant part with your app for quite some version now.

I cannot find anything regarding JavaFX 19 in the current link

Shouldn't the link be https://openjfx.io/highlights/19/ ?

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.

here or lobste.rs are the most coherent forums (fora?) i know of.

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.

JavaFX is not part of the JDK. At least since Java 11 and probably earlier.

Correct. JavaFX is now - other than AWT/Swing - a separate library. I'm sticking with JDK8 where it is integrate but that doesn't matter.

> Including a UI-Toolkit within the base-library of a programming language seems like a mistake.

Sounds subjective.

I would prefer an entire language designed specifically for building native desktop GUI apps because

1. that's the only kind of apps I am interested in developing

2. I hate verbosity/boilerplate, manual labor and uncertainty brought by existence of multiple artificially attached UI toolkits

VisualBasic was sort of such a language but it obviously is obsolete in so many ways.

So, I click on "Documentation" in the top menu, then on "API Documentation" under reference documentation, and I get a 404?

Apparently they haven't updated the docs yet. https://openjfx.io/javadoc/19/ gives a 404, whereas https://openjfx.io/javadoc/18/ works.

There's a quicker intro here to get a flavour of JavaFX https://www.vojtechruzicka.com/javafx-fxml-scene-builder/

Does javafx have any CDI integration for event handling or window management? That’d be the holy grail for me.

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.

I've used CDI with JavaFX. It's nice.

Reply on news.ycombinator.com