Nice to see some freshness pushed into the officially dead model of sharing a JRE between applications instead of going through the pains of the jlink route which seems a bit heavy for many use cases.

Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker? What are the single points of failure for the curated JRE procurement? Is it npm, is it jdeploy, is it adoptium? All of them?

I've done dances like concatenating a zip to a pre-built nsis exe to get a windows installer from a Linux build server, jdeploy sounds like an interesting alternative!

> Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker?

I've seen some interest for self hosting, so it will likely be added. In an earlier iteration (I've been at this for a couple years), it was self hosted, but I found that npm brought a lot to the table and simplified things, so I focused on that.

> What are the single points of failure for the curated JRE procurement?

Here's the process. The launcher (written in C and Go) checks the npm registry to get the app's metadata (e.g. JVM requirements, versions, etc..). If the app needs to be updated, it will update it. If it needs to download a compatible JVM it downloads it. (But it reuses JVMs so if it already has one that meets requirements, it will use that). Currently it downloads from Azul. Used to use Adoptium but switched for JavaFX support reasons.

Any of these pieces could be switched out pretty easily (npm -> self hosting, Zulu -> Adoptium, or self hosted, bundled VM, etc..).

Side note / shout out to Azul for being just great. Their technical support (even while just evaluating Zing) has been excellent and their free Zulu offering is a breeze to install (Debian here).

Interesting project. We build and maintain a significant cross-platform JavaFX app, and use a combination of JLink (to create a smaller executable with bundled JRE), install4j (for the native .app/.exe wrapper) and Packages (macOS)/InnoSetup (Windows) for the installer. The installer has a non-trivial amount of scripting under the hood so being able to customize that is really important, at least for us.

I wonder if you won't run into trouble because of the Mac codesigning/notarization though. I think this poses a significant legal risk to you, as you are now distributing potentially malicious software signed with your certificate. Also I'm pretty certain Apple doesn't like this "code signing as a service" approach.

But hats off, cool project!

Is the lack of notarization truly an issue? Aside from demonstrating that the creator has a paid subscription to the developer program, what does notarization accomplish that isn't already handled by XProtect (i.e. a YARA scan) and the Malware Removal Tool (MRT)?

Are there any examples anywhere of malware that has slipped through the client-side XProtect pre-flight checks, but that the server-side notarization checks have caught? Most independent macOS security literature I've read implies that notarization and code-signing is more about retaining centralized control of the app distribution process, but does not actually contribute anything to the malware mitigation tools that have been built into macOS for a very long time.

Customers don’t want notarization prompts for their expensive, custom-built software packages… So even if the security benefit is negligible (I agree), if you want to play, you have to play by their rules.

> But hats off, cool project!

Thanks!

As someone who's had to recently setup jpackage for one of my side projects, which took forever and a day and I'm still not happy with the result. I'm very interested.

Just glancing at the site, it really looks like this is something you put a bunch of effort into. I'll definitely check this out! So thanks.

> Auto updates. Your users automatically get the latest version on each launch

How do you handle this? Are there hooks so that desktop apps can know to migrate state that's on disk?

The launcher gets the package's metadata from npm's registry on launch. This will tell it the latest version, and also the JVM requirements (e.g. version, javafx, jdk, etc..). It compares this with what it has installed. If it doesn't have the latest version, it will download it. If it already has a JVM that meets the requirements, it uses it. If not, it downloads one from Azul.

When it downloads a new version, it doesn't overwrite old versions. You can have two versions installed simultaneously. They are kept in $HOME/.jdeploy/packages/YOUR-PACKAGE/VERSION

It is also possible to peg your app to a particular version so that it doesn't auto update. Other variations are possible too, such as only autoupdating minor updates. E.g. Update to 2.1 or 2.2, but not to 3.0. For simplicity, I haven't exposes some of that yet.

There are no hooks. When your app runs, it is always running a particular version of the app. If your app needs to "transition" its resources when new versions are run, then that is up to you. No different than if the user downloaded and updated your app manually.

I'd be curious about this one, too. This lib is great, maybe that it plays a role? -> update4J by mordechaim

Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place.

Btw, font on website hurts my eyes, not easy to read. Its a font you'd use only by exception ie. italic usage (e.g. a quote). Not for a whole website.

> Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place.

IMO this is moving back in the direction of the original WORA philosophy of Java. jDeploy is designed to be cross platform. No platform-specific build settings, to as much extent possible. After the death of Applets and WebStart, the new direction of bundle a JRE with every app - and rely on platform-specific 3rd-part tools to create the bundles never felt right to me.

I definitely will not use jDeploy on Linux. Downloaded JVM, without disto-specific patches, is useless, because it will hang or segfault.

I have reproduced this issue, and have posted and update that should fix it. Please try downloading either of the demos again and let me know if it still gives you issues.

I have received a few reports on Linux. I'm working on it. Literally this is the reason why jDeploy is helpful. I've spent 2 years working out many details. Every OS/Version/distribution has needed some special care. Up to now I've been working with a single Ubuntu 20 box for my linux testing. Today, in response to these reports, I'm setting up a number of Linux VMs to test other variations to get to the bottom of this. I should have these issues resolved shortly.

This looks very cool.

What Java framework(Swing, FX etc) would you recommend for a desktop Java app?

In my opinion, JavaFX is the Duke Nukem Forever of UI toolkits. It was supposed to be a "modern" replacement for Swing, ultimately blooming into a full-featured, rich GUI library. But it's now almost 15 years since JavaFX was introduced, and Swing is still much more capable and flexible. I would pick Swing over JavaFX in a heartbeat for a new app right now.

Also, Swing is just there, so for a simple app you don’t need to figure out dependencies or how to fit JavaFX into maven/gradle.

I haven't seemed to be running into any problems ... yet ... with JavaFX maven dependencies. It pretty much Just Works(tm).

A single main dependency (org.openjfx/javafx-control) and a plugin (org.openjfx/javafx-maven-plugin) and you're off to the races. I don't install JFX into the JDK at all (not even sure, honestly, if that's still a thing).

I have more problems with JDK 9 modules (which modern JavaFX seems to support, but good luck with much of anything else of size).

Since I am pretty much awful at GUI programming, I've made a lot more progress with FX on my home projects than Swing. It's no panacea, but it's been working for me.

Did you actually ship the app or is it something small scale?

The pain of JavaFX becomes apparent at deployment time. Installing in a small closed ecosystem is fine. Mass market with all the variance. Ugh.

> figure out dependencies or how to fit JavaFX into maven/gradle.

I struggle with the same thing. jDeploy solves one half of that (deploying javafx is no longer a struggle). I think there is still room to make creating new projects simpler.

Don't do that, use a JVM that includes JavaFX, as this project seems to do. If you use SDKMAN, there are a couple of vendors, including Zulu, that distribute the latest JDKs with JavaFX included.

Liberica too. Crucially they als have a 32-bit Windows build.

> What Java framework(Swing, FX etc) would you recommend for a desktop Java app?

Up to you. Swing is old faithful. JavaFX will result in something that is "cooler" and more modern. Both are supported. If you select "JavaFX" in JRE requirements, it will automatically use a VM with JavaFX to run your app so there's no penalty in app size for using JavaFX.

If you are looking to target mobile, and also want to deploy to Desktop, you might want to check out Codename One. (Full disclosure: I work there).

JavaFX and Swing aren't the only games in town either. jDeploy is part of my desire to make Java a more compelling choice for desktop app development. I still think it is too complex and overwhelming for new comers who just want to make a desktop app. I have some thoughts on how to simplify this, but I'll save that for another thread.

There's an exciting desktop port of https://developer.android.com/jetpack/compose done by Jetbrains: https://github.com/JetBrains/compose-jb

I was thinking that this combo can really change the native desktop development landscape, it's still too early to tell but if you can solve development speed, performance, looking good and easy deployment in one stack it would really improve over Electron based apps.

I agree. Once you fight through the initial project setup, and solve the deployment difficulties (jDeploy), Java is a remarkably good platform for Desktop development. The sheer number of libraries available to you with a simple copy/paste dependency snippet, is unrivalled in any other ecosystem.

It is exciting but even less there than JavaFX unfortunately. That's the problem with most UI systems, they evolve really fast in the beginning and show great promises, then the real difficulties arise and you have users that start to want a stable API.

The thing is that Compose is becoming the de facto UI toolkit for Android, and there is A LOT of really smart people working on it (both at Google and Jetbrains).

Maybe I'm over-hyping it, but I really doubt there has been a UI toolkit with that much work behind in a long time (Maybe Cocoa and one of the last 3 iterations of UI toolkit on Windows had that many work hours, but Cocoa does not work in all OS and the Windows ones well ... :shrug:)

Arguably, Flutter has had even more work done... it's incredible how Flutter tools work so beautifully on all OS's.

I've played with Compose for Desktop and it's basically the Android framework, but running on desktop, as you might expect... but the tooling is currently not anywhere as good as Flutter IMO... and the customizations to make apps look like actual desktop apps (rather than mobile apps on Desktop which is just horrible) is currently impossible because there's just no docs on how to do it or any library that helps achieve that that I could find... Flutter, on the other hand, has multiple "themes" that work well on Desktop... I was amazed to watch a YT video where a Flutter guy showed how he implemented a Windows 3.1- like theme for Flutter and re-created a really old app for a customer that, for users, looks just like the old one (which was a strong requirement by the customer!).

FWIW, there's JetBrains's JetBrainsRuntime project [1] containing Swing patches for eg HiDPI support and other things. Haven't worked with it, nor do I have a stake in it; just mentioning it because JetBrain are one of the few companies delivering kick-ass, commercially successful, mainstream desktop software using Java/Swing today.

[1]: https://github.com/JetBrains/JetBrainsRuntime

Is there a reason these are not getting backported to OpenJDK? I know that jetbrains do contribute a bit, but I feel like their model of having way out of date jdks shipped (offering worse performance then available) is not a good one. (They just recently switched to 11, and was still using the old concurrentms GC, over which G1 runs circles, let alone ZGC)

It is absolutely awful by default; IntelliJ apps are slow to the point of being unusable out of the box. The good news is that it is easily fixed (at least for my use case). I have tinkered a bit and running them on JDK16 or later, with JATOC has been a life-saver for me the past year, and reduced my paying subscription to an act of charity.

"Develop with pleasure" is well and truly dead until they make the out-of-box experience FAST.

What are you comparing against? VSCode with a ton of plugins to almost match IntelliJ? Because that's a lot slower than IntelliJ in my experience, not even close...

I am currently using IntelliJ heavily at work and I would agree it was too slow for a gigantic project we have... but there's literally no alternatives that work nearly as great (Eclipse, Emacs, VSCode, tried them all, they mostly can't even load a project like ours --- Eclipse can but it's a pain to index everything on re-builds)... but since I got a Mac M1 Pro, IntelliJ again feels light and snappy :D unfortunately, having the best hardware possible seems necessary now, as ever.

my expectation is that a 64GB 8 core Intel(R) Xeon(R) CPU E3-1230 v5 @ 3.40GHz with NVMe disk and nvidia graphics on the latest Debian should be much faster running PyCharm than it is in reality.

I develop on mid 2014 15" MacBook Pro mid with 16GB of RAM and 150k LOC Java project works quite ok with latest Idea. It probably depends on what expectations are. It's hardly comparable experience to what was available 10-20 years ago.

Good for you. You are on a platform seemingly preferred by JetBrains.

Its possible to run IntelliJ with a Java 17 runtime now, not out of the box but there is a download somewhere.

Nice work and good explanatory website. I would like an easier process for deploying Java desktop apps, but the solution I use would need to also make it easier for me to deploy to the app stores (aka Mac App Store, Microsoft Store on Windows). Basically I would need a code signed app that I could submit to Apple.

jDeploy can be configured to produce an app like this, where everything is bundled together. It will even automate the codesign and notarize process. However, to do this requires a Mac, and you still need to jump through all Apple's crap for certificates etc... I haven't documented this process officially because I didn't want to confuse the primary message.

For app store builds, jpackage is probably the way to go.

A bugbear of mine having to use a couple of Java apps on my Mac is the non native window support.

Do JBundle'd apps support native full screen size (not just expanding to fill the size of the screen, which allows other app windows to appear in front/behind), and native keyboard shortcut behaviour?

This is more of a GUI concern, and I wouldn't expect a bundler like JDeploy to be able to do something about this.

An appropriate GUI toolkit should be able to integrate with the native fullscreen.

I briefly used the webview for java library [1] and it does the right thing because the browser handles it. JavaFX also supports [2] native fullscreen if appropriate integration is used. Not sure about Swing/AWT etc.

[1] https://github.com/shannah/webviewjar

[2] https://docs.oracle.com/javase/8/javafx/api/javafx/stage/Sta...

SWT offers native UI support for Java apps, but the developer has to integrate it.

https://www.eclipse.org/swt/

The SwingSet demo didn't work at all for me on Linux. (I'm running fully patched Garuda KDE on x64, which is basically arch.)

Thanks. I saw the issue (presumably) you posted, and am setting up a VM to try to reproduce. Should have this fixed shortly.

This is fixed now. If you download the demo again it should work for you.

That fixed it here. It was a little odd that the new download had the same version number as the old, but it worked well.

> It was a little odd that the new download had the same version number as the old

The build number refers to your app version. The download page creates the bundle on the fly (but does cache) using the latest jDeploy release, so when I released the new version of jDeploy, the bundles in the download page are auto-updated. I thought of adding the jdeploy version number into the installer name, but it was getting pretty busy already, so I decided to just leave that off.

No uninstaller on Windows? It doesn't show up neither in old control panel nor new remove programs list.

It's on my todo list. Will be added soon. https://github.com/shannah/jdeploy/issues/27

> Small installer bundle size (3mb compressed)

Is the 3M a launcher to download JRE & .jar files on-demand?

The launcher is about 3 megs compressed. The actual jar files and JVM are downloaded on demand in the $HOME/.jdeploy directory.