11

Is JavaFX 11 cross-platform? As i saw in openjfx.org that i have to download releases for each platform. And if so, can i in any way use it in a cross-platform form? And should i use each javafx release for each java release? Don't tell me to use maven or something like that. I want to program a cross-platform software. And not a multi-release software each release for each OS. I thought to load the modules after checking the OS but can i do that? Any way there is a lot of libraries that are cross-platform even if it have native code so why OpenJFX doesn't do that?

Edit

I didn't test this but maybe we could include all the javafx dependencies for all systems from maven 
<dependency>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-controls</artifactId>
    <version>15.0.1</version>
    <classifier>win</classifier>
</dependency>
<dependency>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-controls</artifactId>
    <version>15.0.1</version>
    <classifier>linux</classifier>
</dependency>
<dependency>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-controls</artifactId>
    <version>15.0.1</version>
    <classifier>mac</classifier>
</dependency>
</dependency>
رامي عبد الله
  • 329
  • 2
  • 11
  • Same issue here. Also creating bundles for different platforms with one click is non-trivial. I've recently started a new project to experiment with an alternative way to deploy applications: Drombler JStore (working title). You can read more about it here: https://puces-blog.blogspot.com/search/label/Drombler%20JStore – Puce Oct 01 '18 at 23:37
  • 2
    The short answer: No. Stay away and try to use Swing instead. – 0__ Aug 14 '19 at 11:10
  • @0__ I must say that I totally agree with you. It's disappointing that JavaFX is not part of Java SE so that we have to add it to our dependencies, resulting in a heavy JAR. I used JavaFX for a help system based on HTML since there's no decent HTML text component in Swing/AWT. If there would be a modern (HTML5) component in Swing I'd drop JavaFX immediately! – Hummeling Engineering BV Jun 23 '20 at 21:37
  • @HummelingEngineeringBV You're "supposed" to package your desktop application with `jlink` and/or `jpackage`, making the fact JavaFX is not included in Java SE irrelevant. – Slaw Jan 17 '21 at 06:52
  • @Slaw, packaging my desktop apps with `jpackage` make the apps even heavier, since it includes an entire JRE. I'd agree it's a robust solution, but it's certainly not elegant for distributing small (light) apps. – Hummeling Engineering BV Feb 07 '21 at 14:15
  • @HummelingEngineeringBV I disagree that it's inelegant, unless you're distributing to extremely space-limited devices. In my opinion, what is inelegant is to require the end user have specific versions of Java, possibly from a specific vendor, installed. And in the case of space-limited devices you likely have more control anyway so that you can force a JRE with JavaFX to be installed (some vendors provide this, or you can build your own independent-of-your-apps-JRE that includes JavaFX via `jlink`). But ultimately, if this is a problem then I agree one should avoid JavaFX. – Slaw Feb 07 '21 at 20:55
  • @Slaw I rarely encountered issues with different versions of Java. For us, the whole benefit of Java is that there's a JRE on all target machines, so we don't have to worry about that as we develop and distribute our apps. Although it had its flaws, I liked the deployment and automatic updating mechanism of JNLP. But that's also gone, so mind as well develop in C++. Will also give me calculation performance benefits... Nowadays it seems no one cares to be waiting for software to (down)load, while it really disturbs me. Don't see why this would be necessary with high speed pc's and Internet?! – Hummeling Engineering BV Feb 10 '21 at 21:16
  • @HummelingEngineeringBV That's fair. Personally, I'd rather code in Java than C++ regardless. You can also check out GraalVM's native image if you want ahead-of-time compilation for Java. But just to reiterate, the fact Oracle does not include JavaFX in their JDK (Oracle doesn't even offer a JRE-only download anymore) still seems irrelevant to me. Other vendors do provide JREs with JavaFX, or you can build and distribute your own via `jlink`. – Slaw Feb 10 '21 at 21:47
  • @Slaw From a coding perspective I also prefer Java over C++. Nonetheless, the idea behind the JVM (or at least Oracle's) is that it should contain _base Java_. So the discussion boils down to: should JavaFX belong to that base part or should it be regarded as some optional library? Since JavaFX is considered a replacement for Swing/AWT, I argue that is should be part of this base. I can't rely nor dictate that all my target machines have GraalVM or any other JVM that ships with JavaFX. – Hummeling Engineering BV Feb 11 '21 at 13:13

2 Answers2

17

JavaFX 11 is not part of the JDK any more, and it is distributed now in two flavors:

When you download the JavaFX SDK you have to choose a platform, the same as when you install the JDK for your platform. It remains cross-platform in terms of API, so your code will look the same on every platform, but it is platform-specific in terms of SDK/dependencies.

The reason for that is the native libraries that are bundled with each SDK.

If you have a look at the three JavaFX 11 SDK bundles each of them zipped has around 40 MB:

  • Windows: 39.7 MB zipped, 64.8 MB in dll libraries (jfxwebkit.dll only has 59.2 MB), and 15.5 MB in jars and source.
  • Mac: 39.7 MB zipped, 72.2 MB in dylib libraries (libjfxwebkit.dylib only has 67.8 MB), and 15.6 MB in jars and source.
  • Linux: 43.8 MB zipped, 84.9 MB in so libraries (libjfxwebkit.so only has 80.1 MB), and 15.8 MB in jars and source.

Now the question is: would you bundle the three platforms in one? Total zipped size of 120 MB, unzipped native libraries for three platforms around 220 MB?

There was a debate about this issue precisely in the openjfx-dev mailing list, but I believe the taken approach is the correct one.

If you use Maven/Gradle and retrieve your dependencies from Maven Central, on Gradle you have to specify the classifier for your plaform. See the Getting Started sample. Maven does it internally, so even if you don't set the classifier, it only download the jars for your platform.

So for a regular project where you don't use WebView, it could make sense, as you will download only the required modules dependencies for your platform: javafx.base, javafx.graphics, javafx.controls and javafx.fxml.

But so far, and that's not something that can be changed now, you get your platform-agnostic JavaFX API but with platform-specific JavaFX SDK/modules.

Note that when you distribute a JavaFX application, you will use the Jpackager and you will release three different versions for the three different platforms, so either way you are in need of a platform-specific distribution.

José Pereda
  • 44,311
  • 7
  • 104
  • 132
  • 5
    As usual i release one jar to the three platforms. So i have to distribute one version for the three platforms. But as i understood i have to download JavaFX from Maven and JavaFX SDK will be bundled with the dependancies. If that is right the software will not be cross-platform like that. This is not a solution at all. Does that meaning that JavaFX will not be cross-platform? For now i develope JavaFX projects on Java 8 for that reason and because the 9+ Java versions doesn't support 32 bit computers. Does that safe?. – رامي عبد الله Oct 05 '18 at 08:31
  • 3
    As I mentioned in my answer, you will be using Jpackager to create an installer for each platform. But if you want to create an distribute a single jar for all platforms, you still can do that. In this [answer](https://stackoverflow.com/a/52654791/3956070) I mention that you can include the three native dependencies in one single jar as well. – José Pereda Oct 05 '18 at 09:05
-2

JavaFX is written in Java, which is ran on the JVM, which is cross-platform. So that would mean JavaFX is also cross-platform.

You download different releases to run the JVM on your machine. But your JavaFX code can be run on any of these releases, so it's cross-platform.