14 ms·

JavaFX 19

85 points by obdev 4y ago

whartung 4y ago
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.
- jjtheblunt 4y ago
  here or lobste.rs are the most coherent forums (fora?) i know of.
capableweb 4y ago
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 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.
- sph 4y ago
  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?
  - vbezhenar 4y ago
    Clojure is compatible. GraalVM is not compatible.
  - ipsi 4y ago
    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.
    - kaba0 4y ago
      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.
  - chrisseaton 4y ago
    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.
- ipsi 4y ago
  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.
- cmiles74 4y ago
  You can definitely call JavaFX from Clojure. There's also the cljfx project that is "declarative and functional". :-) https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
- phforms 4y ago
  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.
  - karmakaze 4y ago
    What were the startup times like without AOT and how large/complex was your prototype?
- zeroth32 4y ago
  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?)
  - rroot 4y ago
    https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/
  - usrusr 4y ago
    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".
Dig1t 4y ago
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.
- cies 4y ago
  > you can ship on all the platforms Except Linux/Wayland for now... https://youtrack.jetbrains.com/issue/JBR-3206 https://youtrack.jetbrains.com/issue/JBR-3206 https://wiki.openjdk.org/display/wakefield https://wiki.openjdk.org/display/wakefield
  - marwis 4y ago
    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 :)
maxpert 4y ago
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?
- grandinj 4y ago
  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.
- hackarama 4y ago
  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.
- seanalltogether 4y ago
  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.
- ludovicianul 4y ago
  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.
  - kaba0 4y ago
    Well, Qt’s tradeoff is that it is C++ and python-only.
- 4y ago
kleiba 4y ago
So, I click on "Documentation" in the top menu, then on "API Documentation" under reference documentation, and I get a 404?
- tpxl 4y ago
  Apparently they haven't updated the docs yet. https://openjfx.io/javadoc/19/ https://openjfx.io/javadoc/19/ gives a 404, whereas https://openjfx.io/javadoc/18/ https://openjfx.io/javadoc/18/ works.
vlaaad 4y ago
Found release notes: https://gluonhq.com/products/javafx/openjfx-19-release-notes/ https://gluonhq.com/products/javafx/openjfx-19-release-notes... Mostly bugfixes.
hackarama 4y ago
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.
- whartung 4y ago
  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 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.
- cnr 4y ago
  Unfortunately the "magic green >>Build<<" button (at least for JDK11+ projects) is still missing :( Check: https://youtrack.jetbrains.com/issue/IDEA-20072 https://youtrack.jetbrains.com/issue/IDEA-20072
- lokedhs 4y ago
  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.
ianpurton 4y ago
There's a quicker intro here to get a flavour of JavaFX https://www.vojtechruzicka.com/javafx-fxml-scene-builder/ https://www.vojtechruzicka.com/javafx-fxml-scene-builder/
ephaeton 4y ago
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'.
- usrusr 4y ago
  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.
  - ephaeton 4y ago
    in that respect, everything's 'next gen'...
    - TheCondor 4y ago
      Until it becomes “modern”
      - cbm-vic-20 4y ago
        And then, "classic".
exabrial 4y ago
Does javafx have any CDI integration for event handling or window management? That’d be the holy grail for me.
- whartung 4y ago
  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.
towawy 4y ago
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 https://github.com/SpaiR/imgui-java
- zelos 4y ago
  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.
- ludovicianul 4y ago
  You can bundle the JRE with the app using https://docs.oracle.com/javase/9/tools/jlink.htm https://docs.oracle.com/javase/9/tools/jlink.htm and use https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... to create distributions for the main platforms.
- kaba0 4y ago
  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.
ho_schi 4y ago
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.
- qwerty456127 4y ago
  > 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.
- oweiler 4y ago
  JavaFX is not part of the JDK. At least since Java 11 and probably earlier.
  - ho_schi 4y ago
    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.
kaeruct 4y ago
I cannot find anything regarding JavaFX 19 in the current link Shouldn't the link be https://openjfx.io/highlights/19/ https://openjfx.io/highlights/19/ ?

85 points by obdev 4y ago

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.

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

capableweb 4y ago

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

sph 4y ago
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?
- vbezhenar 4y ago
  Clojure is compatible. GraalVM is not compatible.
- ipsi 4y ago
  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.
  - kaba0 4y ago
    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.
- chrisseaton 4y ago
  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.
ipsi 4y ago
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.
cmiles74 4y ago
You can definitely call JavaFX from Clojure. There's also the cljfx project that is "declarative and functional". :-) https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
phforms 4y ago
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.
- karmakaze 4y ago
  What were the startup times like without AOT and how large/complex was your prototype?
zeroth32 4y ago
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?)
- rroot 4y ago
  https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/
- usrusr 4y ago
  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".

Dig1t 4y ago

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.

cies 4y ago
> you can ship on all the platforms Except Linux/Wayland for now... https://youtrack.jetbrains.com/issue/JBR-3206 https://youtrack.jetbrains.com/issue/JBR-3206 https://wiki.openjdk.org/display/wakefield https://wiki.openjdk.org/display/wakefield
- marwis 4y ago
  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 :)

maxpert 4y ago

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?

grandinj 4y ago
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.
hackarama 4y ago
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.
seanalltogether 4y ago
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.
ludovicianul 4y ago
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.
- kaba0 4y ago
  Well, Qt’s tradeoff is that it is C++ and python-only.
4y ago

kleiba 4y ago

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

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

vlaaad 4y ago

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

hackarama 4y ago

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.

whartung 4y ago
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 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.
cnr 4y ago
Unfortunately the "magic green >>Build<<" button (at least for JDK11+ projects) is still missing :( Check: https://youtrack.jetbrains.com/issue/IDEA-20072 https://youtrack.jetbrains.com/issue/IDEA-20072
lokedhs 4y ago
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.

ianpurton 4y ago

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

ephaeton 4y ago

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

usrusr 4y ago
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.
- ephaeton 4y ago
  in that respect, everything's 'next gen'...
  - TheCondor 4y ago
    Until it becomes “modern”
    - cbm-vic-20 4y ago
      And then, "classic".

exabrial 4y ago

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

whartung 4y ago
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.

towawy 4y ago

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 https://github.com/SpaiR/imgui-java

zelos 4y ago
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.
ludovicianul 4y ago
You can bundle the JRE with the app using https://docs.oracle.com/javase/9/tools/jlink.htm https://docs.oracle.com/javase/9/tools/jlink.htm and use https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... to create distributions for the main platforms.
kaba0 4y ago
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.

ho_schi 4y ago

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.

qwerty456127 4y ago
> 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.
oweiler 4y ago
JavaFX is not part of the JDK. At least since Java 11 and probably earlier.
- ho_schi 4y ago
  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.

kaeruct 4y ago

I cannot find anything regarding JavaFX 19 in the current link Shouldn't the link be https://openjfx.io/highlights/19/ https://openjfx.io/highlights/19/ ?