It does just work, at least compared to web apps. I have experience of both web dev and distributing a somewhat complex JavaFX app to consumers. I bundled the JRE with my app so the users did not need to have Java installed.

The leaks in the operating system abstraction Java gives you are really quite small. I wrote my entire app on macOS and tested on Linux/Windows only right at the end - after about 8 months of full time dev work I spent about a day addressing platform specific issues. That's pretty good.

Now compare that to the mess that web browsers were and still are. It's better than it once was, but you're going to have to check every single feature of HTML5 you use to figure out which browsers implement it, which don't, which use vendor prefixes still, which only half implement it, which don't but can be shimmed using big blobs of JavaScript and so on. The web absolutely doesn't "just work": you will spend more far time working around browser specific issues than you will spend dealing with OS specific issues in Java.

> you're going to have to check every single feature of HTML5 you use ... you will spend more far time working around browser specific issues than you will spend dealing with OS specific issues in Java.

I'm confused at this comparison in terms of Electron. Do you have to worry about any of that when doing an Electron app? Or were you making a comparison between JavaFX and web dev?

You're right that with Electron that's not an issue as you control the browser. I was comparing the equivalent issue in web dev to the "write once run anywhere" issue in Java. If you pick the users operating system e.g. only support Windows then of course, there are no cross platform issues with Java either

> I bundled the JRE with my app so the users did not need to have Java installed.

Side note here: do you track security vulnerabilities of the shipped JRE and provide updates when it happens?

Too often, I've seen java applications shipping obsolete and vulnerable JRE. And in some cases, I've seen not consistent versions across a product line.

Also wasn't there some unknowns about the right to redistribute the Oracle JRE?

I do track those. I didn't need to update my app at any point for them because most vulnerabilities in the JRE are to do with sandbox escapes and my app did not run potentially malicious code.

> Also wasn't there some unknowns about the right to redistribute the Oracle JRE?

Nope, Oracle clearly says you can in their FAQ:

https://java.com/en/download/faq/distribution.xml

> It's better than it once was, but you're going to have to check every single feature of HTML5 you use to figure out which browsers implement it

There's tools for that and i'm pretty sure just writing plain html and css or some compile-to-js would have shaved off significant time from that 8 month full dev time.

It wouldn't have been possible to do as a webapp at all, as the app in question was a peer to peer app that spoke a fairly complex network protocol that doesn't support WebSockets (Bitcoin). But even if that issue hadn't existed, the development time went mostly on logic and p2p/networking issues. HTML wouldn't have helped and JavaFX supports a dialect of CSS2 anyway.

Javafx includes a packager tool which creates a native application with the runtime bundled inside. There is nothing to install.

Once the runtime is bundled in, what does the size of the standalone application come in at? Curious if it is close that of a bare Electron app (around 50-90 MB, depending on the platform).

In my project, the jar file itself is 20MB, and the resulting files generated by javapackager are: 55MB (.exe), 90MB (.dmg), and 67MB (.deb), all of which include the jar file inside them. These are not the total file size after installation, though.

Was this using the "javapackager" tool? This seems to have been introduced in Java 1.7 as far as I can tell.

Yes, I mentioned javapackager in the comment.

Hmm, indeed it does, but I could have swore that the first time I read the comment it didn't. I guess I forgot how to read earlier :-)

Yes in Java 8 it's comparable. In 9 it should be smaller due to some dead code elimination on module boundaries, but 9 just came out so it's a bit early for people to have experience with it yet.

Note that even in 8 you can do a DCE pass over the code and erase files you know you won't need from the JRE image by hand. I did this and shrank the size of the download by about half. The JavaScript world calls this "tree shaking", you can use ProGuard to do it in Java but it's a bit fiddly to set up.

For Java 8 it is about 200mb. Java 9 should be smaller because it should only bundle the parts the app actually used.

Isn’t that the JDK, the jre is smaller from what I remember.

.NET could use that.

.NET Core can do that:

https://docs.microsoft.com/en-us/dotnet/core/deploying/deplo...

.NET Core unfortunately doesn't support WPF . I think UWP isn't supported either.

The official native UI for .NET Core being discussed at .NET Conf 2017 was Xamarin.Forms, as they are adding macOS, Linux and WPF support as well.

Generally java desktop software is wrapped together with a bundled jre and behaves like an executable without external dependencies. There are a bunch of ways to do this. For example: https://github.com/libgdx/packr

Correct me if I'm wrong, but I don't think the Java updaters on Windows do bundleware anymore. I know nearly all the free Windows antivirus updaters automatically install Chrome and set it as your default browser unless you pay close attention still.

The damage is done. Thank you Oracle.

That "bundleware" (as JohnTHaller calls it) stuff was going on before Oracle. I recall being disappointed that Oracle hadn't stopped it several versions into the Oracle rebranding.

Sun did that damage.

Yeah I haven’t even had java installed in years. Only have a single app that uses it but it’s tucked away in a docker container. It’s basically flash to be, no longer a need.

I have an old release of Photoshop, didn't even install it because it demanded such an old version of Java.

Yeah, try getting any Java program to work on a Chrome box.

… especially if there's a dependency on JavaFX which is not available by default with every “Java” out there (eg. OpenJDK on Ubuntu).

I reported a bug on Launchpad last week for the missing JavaFX support in the Ubuntu OpenJDK package.

For details, see "JavaFX support is in upstream OpenJDK 9 but missing in Ubuntu OpenJDK 9" (https://bugs.launchpad.net/ubuntu/+source/openjdk-9/+bug/172...).

this is why you package the whole JVM with it. This leads to a native executable without any dependencies (e.g. IntelliJ products)