You've been able to package your java apps so to not require that from your users for a very long time, and in the more recent years, with the compartmentalization of the JDK, you've been able to ship a very striped down version of it, and even more recently, an AOT compiled/PGO optimized binary, so nowadays you can ship your instant starting/low footprint/well performing java code without Java/a JVM.
At some point you need to ship the runtime, right? Even native (Go, Rust, C++, …), depending on how you do the linking. What would make it more acceptable in this case is that you would strip down the JVM and only ship the modules depended upon (whereas Chromium is a monolith) when using jlink, and on top of that, native-image does some PGO, inlining and dead-code elimination AFAICT.
OpenJDK doesn't do the AOT compilation part, you have to use GraalVM native-image for that and it's somewhat experimental for desktop apps. But otherwise it's pretty easy to bundle stuff up.
2. Run `conveyor generate {javafx,compose} my-test-project` (pick your preferred UI toolkit). You now have a JVM desktop project.
3. `./gradlew jar; conveyor make site`. You now have a directory with self-updating platform native packages for Windows, macOS (ARM/Intel) and Linux that you can upload to a web server of your choice. Or supply upload creds and it'll do that step for you. Provide certificates and it'll also take care of signing.
That's all it takes to get a self-updating JVM desktop app these days. The same tool can do Electron, Flutter and native apps too (i.e. C++/Rust), so you could also use it with Tauri, but the nice thing about the JVM support is that it'll both strip down and bundle the JVM for you whilst cross-building/packaging so you don't need CI to do releases. From the user's perspective it's a normal app, from the developer's perspective you just hack on your local dev laptop like you could for a web app.
Binary sizes depend on how much functionality you use and how much effort you put into minifying. With the default level of effort (i.e. none) a simple hello world JavaFX desktop app will be about 33mb and a simple compose app will be about 52mb for macOS (skia is a very large graphics library). However, the Mac versions are larger than those for other platforms, and these sizes are still quite wasteful. There's a lot of low hanging fruit. You could make it a fair bit smaller by using ProGuard and other more aggressive dead code elimination techniques, as well as more heavily compressing bytecode. There's also plenty of fat to trim on the native code side.
GraalVM native images are interesting because they have much faster startup time and low memory usage - competitive with C++ apps, even. They take more work to create though. You can see a robotics app that's natively compiled here:
JLink (JEP 282) does the first part and was released with Java9 (6 years ago), the native compilation stuff is a product of GraalVM. Binaries are reasonably small but it depends of course on what your app is doing. There is a whole ecosystem of web frameworks that's being built on that (quarkus.io, micronaut) and IIRC you can build a simple REST API that ships as a <20MB container.
JavaFX supports a WebKit based WebView widget, but it's optional. If you don't use it it's not bundled. If you do then you pay the cost of including the WebKit build which is ~80mb.
In practice the need for WebKit is going down over time. For basic rich text you can render Markdown to JavaFX nodes directly, for more advanced stuff you could transform [X]HTML to FXML, you don't need it for video or audio, there's a native rich text / word processor control these days, and if you can do 3D graphics with a high level scene graph (meshes, lights etc) then you don't need HTML for 3D either.
Still, it's often useful and bandwidth/disk space isn't the problem it once was.
Are you the Mike Hearn from the bitcoin and "history is a scam" fame? Cool to see you here :) I somehow am (positively!) surprised to see your name in relation to Java GUI frameworks. Hydraulic Conveyor looks interesting, is it planned to support GraalVM's native-image? Would it work with Scala/ScalaFX?
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way. There's also someone in our Discord who has been trying it with Compose apps.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff. OTOH if you don't care about that, it'd be (imo) easier and more direct to not use HTML. Proper GUI toolkits give you a lot of stuff out of the box like virtualized list views which HTML still doesn't; useful for scrolling over huge datasets like chat logs.
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
Thanks for the reply, I'll definitely keep an eye on all that.
> For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff.
I'm not even sure it matters so much, for instance there is this XMPP client that uses (lib)WebRTC for audio/video calls and has all of its UI build with Gtk (no web): https://dino.im/
> Proper GUI toolkits give you a lot of stuff out of the box […] Also I learned GUI programming decades ago and find classical UI toolkit more intuitive than HTML.
yep, looks like we are on the same boat of angry old men yelling at clouds :)
TIL, I haven't been using Java-based software for a long time (and I still have vivid memories of having to install the correct version of the JDK before installing one).
