7 ms·

Successfully using JavaFX (or OpenJFX as it is now called) in a mission-critical cross-platform app with 50k+ installs. It’s not that bad really. Package size

Successfully using JavaFX (or OpenJFX as it is now called) in a mission-critical cross-platform app with 50k+ installs. It’s not that bad really. Package size and RAM usage is a bit of an issue, as we bundle it with a jlink’ed (stripped down to what is needed, thanks to Java 9 modules) JDK. Other options like Electron or native Windows/macOS wrappers around a shared core written in C++ were discussed but ultimately discarded. Still happy with the choice, although it feels a bit dated and IDE support (IntelliJ) is so so.

TheRealSteel 5y ago
I'm working on a personal project at the moment that uses a shared C++ core across Android and iOS. (It's an image processing plugin for Unity, no GUI, so cross platform frameworks aren't suitable). It was complicated to setup, but I'm glad I did. Only having to write 99% of the code once is a life saver.
alex_suzuki 5y ago
Just to elaborate, we make heavy use of JNA to interface with platform-specific facilities such as Keychain, Notifications, etc. JNA is an awesome piece of technology.
tombert 5y ago
I had to use OpenJFX for school recently, and while I still hate the Java language, I had to begrudgingly admit that JavaFX really wasn't that bad at all. It more or less did what I wanted it to do, the resulting GUI didn't look too bad, and it performed well enough. I ended up using it for a Clojure app a bit later. It's good enough to where I think that if JavaFX had come out around the same time as Swing, the Java GUI would substantially more popular. As it stands, when I tell people I'm using JavaFX, they either don't know what I'm talking about, or they'll say "isn't that just Swing? Yuck!"
- Tsarbomb 5y ago
  I hate the old school way of writing Java more than any other language. I love writing in "modern" Java more than any other language. Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.
  - zaphirplane 5y ago
    Lombok is too much magic for me, record class and the annotation generators libraries are a bit less magic
    - jsiaajdsdaa 5y ago
      >Lombok is too much magic for me If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually. Any other usage of Lombok is possibly indicative of a questionable application design imo
  - tombert 5y ago
    Haven't used Lombox, RxJava is great, but it just feel like bandaids on a language that wasn't really designed for it. There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.
    - softwarebeware 5y ago
      Scala is far ahead of its time. And has been since 2014.
    - deleted 5y ago
      [deleted]
    - Cthulhu_ 5y ago
      Lombok is indeed a band-aid that replaces IDE-autogenerated code, which in turn is a band-aid for language design choices on the one hand (e.g. equals and hashcode), and accepted Best Practices in Java world like setters/getters everywhere; for the latter, you can either do public final fields, just use public fields until you need an accessor method (java's refactorings are great), or on the other hand add language features like in C# and Scala where from a class consumer point of view, accessing a value or calling a setter/getter are the same. That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless. If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.
- geokon 5y ago
  In Clojure you can use JavaFX through cljfx https://github.com/cljfx/cljfx/ https://github.com/cljfx/cljfx/ I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy. My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps
  - thom 5y ago
    I’ve found cljfx very productive. Steep learning curve, and the abstractions are somewhat leaky, but it’s worth the pain around the edges for the core workflow. Wrapping controls like ControlsFX is trivial. We’ve written a wrapper for TestFX as well so we have full functional tests and everything gets built, tested, jlinked and jpackaged continuously. It’s been one of the least painful projects I’ve ever worked on tbh.
    - kaliszad 5y ago
      Do you have any good resources on how to use jlink/ jpackage with Clojure? Do you somehow embed it in a Uberjar or is the Uberjar part of the package besides the JRE?
      - thom 5y ago
        You build your Clojure app as an uberjar, yes. Only gotcha here is to remember "-Dcljfx.skip-javafx-initialization=true" so the JFX thread doesn't get started during build, and I've had no problems using Clojure's direct linking either. You use jlink[1] to create a custom runtime JRE image (this isn't strictly necessary if you're deploying to machines with a JRE but it cuts down on moving parts and gives you more control). jpackage[2] then takes that runtime image and your uberjar and creates installers for Mac/Windows/Linux. Both are command line tools, and we just have GitHub Actions that cut new releases for each platform when we tag something with a new version. Worth also keeping an eye on jDeploy[3] which adds extra goodies like auto updates, at the cost of some npm shenanigans. Not something I've played with yet though. 1: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jlink.html https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli... 2: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa... 3: https://www.jdeploy.com/ https://www.jdeploy.com/
wellpast 5y ago
What's your product - if you don't mind sharing?
- sirius87 5y ago
  Not OP, but if you're looking for a quick look, I use AudioBookConverter [1] that uses OpenJFX to execute ffmpeg commands to build M4B files. It's very clunky, especially when you install updates and such. But it gets the job done. [1] https://github.com/yermak/AudioBookConverter https://github.com/yermak/AudioBookConverter
kitsunesoba 5y ago
Have you by chance had any experience with using Kotlin with JavaFX/OpenJFX? I've never been much of a fan of Java, but have had a fair amount of exposure to Kotlin via Android development and have found it fairly pleasant to work with, so if it meshes well with OpenJFX that may appeal to me as an option for cross-platform desktop dev.
- rOOb85 5y ago
  I love kotlin and have messed around with javafx + kotlin. It works well once you have set it up.
  - xhevahir 5y ago
    Do you mean TornadoFX, or some other kind of JavaFX-with-Kotlin?
    - perrylaj 5y ago
      I wouldn't use Tornado - it's effectively dead. Hasn't been a commit merged in for 5 months, and doesn't seem any forks have really picked up the mantle.
    - brabel 5y ago
      In Kotlin, you can use any Java library without a wrapper. That includes JavaFX of course. TornadoFX is only a convenience skin on top of JavaFX to make Kotlin code more concise (but it's heavier also as it adds a lot of code to your application).
karmakaze 5y ago
JavaFX was pretty good when I evaluated it around the time of JDK7/8. At the time I was also looking into other Rich Client Platforms: Adobe AIR, MS Silverlight, Eclipse RCP, and (sort-of-not really) Netbeans. Any of them could techically be used but JavaFX was the most open and likely to be supported at that time. Used it for come proof-of-concepts and it worked fine, though it took some re-orientation for some devs.
camhart 5y ago
Java apps can't be notarized for MacOS according to the developer agreement.
- perrylaj 5y ago
  Can you expand on this? I know for a fact they can be _technically_ notarized, which developer agreement bans it?
- pjmlp 5y ago
  They surely can, it is a matter of using the right tools. https://gluonhq.com/products/mobile/vm/ https://gluonhq.com/products/mobile/vm/ https://www.codenameone.com/ https://www.codenameone.com/
billfruit 5y ago
The unbundling of JavaFx from JDK has made using JavaFx a bit of a chore in a new project. I think it was a bad move, and has made the future of JavaFx uncertain. Question is can JavaFx be recommended for a new project, given the uncertainty of its future and lack of popularity.
deepsun 5y ago
Last time I used jlink it produced a bunch of folders and a shell file to launch. Is it possible to make it a single binary executable instead (preferrably without GraalVM)? Also I tried to get rid of unused classes using Proguard, but there are zero tutorials for non-Android java apps.
- kaba0 5y ago
  You need jpackage for that, which will create a native executable (unfortunately only for the given platform)

TheRealSteel 5y ago

I'm working on a personal project at the moment that uses a shared C++ core across Android and iOS. (It's an image processing plugin for Unity, no GUI, so cross platform frameworks aren't suitable). It was complicated to setup, but I'm glad I did. Only having to write 99% of the code once is a life saver.

alex_suzuki 5y ago

Just to elaborate, we make heavy use of JNA to interface with platform-specific facilities such as Keychain, Notifications, etc. JNA is an awesome piece of technology.

tombert 5y ago

I had to use OpenJFX for school recently, and while I still hate the Java language, I had to begrudgingly admit that JavaFX really wasn't that bad at all. It more or less did what I wanted it to do, the resulting GUI didn't look too bad, and it performed well enough. I ended up using it for a Clojure app a bit later. It's good enough to where I think that if JavaFX had come out around the same time as Swing, the Java GUI would substantially more popular. As it stands, when I tell people I'm using JavaFX, they either don't know what I'm talking about, or they'll say "isn't that just Swing? Yuck!"

Tsarbomb 5y ago
I hate the old school way of writing Java more than any other language. I love writing in "modern" Java more than any other language. Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.
- zaphirplane 5y ago
  Lombok is too much magic for me, record class and the annotation generators libraries are a bit less magic
  - jsiaajdsdaa 5y ago
    >Lombok is too much magic for me If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually. Any other usage of Lombok is possibly indicative of a questionable application design imo
- tombert 5y ago
  Haven't used Lombox, RxJava is great, but it just feel like bandaids on a language that wasn't really designed for it. There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.
  - softwarebeware 5y ago
    Scala is far ahead of its time. And has been since 2014.
  - deleted 5y ago
    [deleted]
  - Cthulhu_ 5y ago
    Lombok is indeed a band-aid that replaces IDE-autogenerated code, which in turn is a band-aid for language design choices on the one hand (e.g. equals and hashcode), and accepted Best Practices in Java world like setters/getters everywhere; for the latter, you can either do public final fields, just use public fields until you need an accessor method (java's refactorings are great), or on the other hand add language features like in C# and Scala where from a class consumer point of view, accessing a value or calling a setter/getter are the same. That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless. If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.
geokon 5y ago
In Clojure you can use JavaFX through cljfx https://github.com/cljfx/cljfx/ https://github.com/cljfx/cljfx/ I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy. My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps
- thom 5y ago
  I’ve found cljfx very productive. Steep learning curve, and the abstractions are somewhat leaky, but it’s worth the pain around the edges for the core workflow. Wrapping controls like ControlsFX is trivial. We’ve written a wrapper for TestFX as well so we have full functional tests and everything gets built, tested, jlinked and jpackaged continuously. It’s been one of the least painful projects I’ve ever worked on tbh.
  - kaliszad 5y ago
    Do you have any good resources on how to use jlink/ jpackage with Clojure? Do you somehow embed it in a Uberjar or is the Uberjar part of the package besides the JRE?
    - thom 5y ago
      You build your Clojure app as an uberjar, yes. Only gotcha here is to remember "-Dcljfx.skip-javafx-initialization=true" so the JFX thread doesn't get started during build, and I've had no problems using Clojure's direct linking either. You use jlink[1] to create a custom runtime JRE image (this isn't strictly necessary if you're deploying to machines with a JRE but it cuts down on moving parts and gives you more control). jpackage[2] then takes that runtime image and your uberjar and creates installers for Mac/Windows/Linux. Both are command line tools, and we just have GitHub Actions that cut new releases for each platform when we tag something with a new version. Worth also keeping an eye on jDeploy[3] which adds extra goodies like auto updates, at the cost of some npm shenanigans. Not something I've played with yet though. 1: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jlink.html https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli... 2: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa... 3: https://www.jdeploy.com/ https://www.jdeploy.com/

wellpast 5y ago

What's your product - if you don't mind sharing?

sirius87 5y ago
Not OP, but if you're looking for a quick look, I use AudioBookConverter [1] that uses OpenJFX to execute ffmpeg commands to build M4B files. It's very clunky, especially when you install updates and such. But it gets the job done. [1] https://github.com/yermak/AudioBookConverter https://github.com/yermak/AudioBookConverter

kitsunesoba 5y ago

Have you by chance had any experience with using Kotlin with JavaFX/OpenJFX? I've never been much of a fan of Java, but have had a fair amount of exposure to Kotlin via Android development and have found it fairly pleasant to work with, so if it meshes well with OpenJFX that may appeal to me as an option for cross-platform desktop dev.

rOOb85 5y ago
I love kotlin and have messed around with javafx + kotlin. It works well once you have set it up.
- xhevahir 5y ago
  Do you mean TornadoFX, or some other kind of JavaFX-with-Kotlin?
  - perrylaj 5y ago
    I wouldn't use Tornado - it's effectively dead. Hasn't been a commit merged in for 5 months, and doesn't seem any forks have really picked up the mantle.
  - brabel 5y ago
    In Kotlin, you can use any Java library without a wrapper. That includes JavaFX of course. TornadoFX is only a convenience skin on top of JavaFX to make Kotlin code more concise (but it's heavier also as it adds a lot of code to your application).

karmakaze 5y ago

JavaFX was pretty good when I evaluated it around the time of JDK7/8. At the time I was also looking into other Rich Client Platforms: Adobe AIR, MS Silverlight, Eclipse RCP, and (sort-of-not really) Netbeans. Any of them could techically be used but JavaFX was the most open and likely to be supported at that time. Used it for come proof-of-concepts and it worked fine, though it took some re-orientation for some devs.

camhart 5y ago

Java apps can't be notarized for MacOS according to the developer agreement.

perrylaj 5y ago
Can you expand on this? I know for a fact they can be _technically_ notarized, which developer agreement bans it?
pjmlp 5y ago
They surely can, it is a matter of using the right tools. https://gluonhq.com/products/mobile/vm/ https://gluonhq.com/products/mobile/vm/ https://www.codenameone.com/ https://www.codenameone.com/

billfruit 5y ago

The unbundling of JavaFx from JDK has made using JavaFx a bit of a chore in a new project. I think it was a bad move, and has made the future of JavaFx uncertain. Question is can JavaFx be recommended for a new project, given the uncertainty of its future and lack of popularity.

deepsun 5y ago

Last time I used jlink it produced a bunch of folders and a shell file to launch. Is it possible to make it a single binary executable instead (preferrably without GraalVM)? Also I tried to get rid of unused classes using Proguard, but there are zero tutorials for non-Android java apps.

kaba0 5y ago
You need jpackage for that, which will create a native executable (unfortunately only for the given platform)