shannah78

Yes, there is an app alternative. You can generate an .app directly with jdeploy. However, then you need to code-sign and notarize the app if you want users who download it to not see a "This app is damaged" message. The installer solve the code-sign problem because the installer is code-signed, and it reuses the same installer app for apps. When the app itself is installed in this way, it doesn't face the same quarantine restrictions as it would if it were downloaded from the internet.

Yes the jDeploy installer is codesigned and notarized. The same installer is reused for every app. It figures out the specific app to be installed from a code in the installer name, so that, when run, the installer installs the correct app.

With a pkg I would need a different pkg for every app - which would need to be codesigned. Then we're back at the "need a mac to build mac app" issue. I wanted jDeploy fulfill WORA to whatever extent possible.

By managing the JVMs separately, you get major savings on updates, or if you have multiple apps deployed this way since they can share a JVM. When you update your app, it only needs to download your app - not the whole JVM. You can even change the JVM requirements in your version updates, and it will adjust to the new requirements when it updates, possibly even downloading a new JVM if it doesn't have one that meets the requirements yet.

What version of Mac OS are you using? I've been testing on Mojave, Catalina, Big Sur, and Monterey. Can't seem to reproduce this (the "SwingSet2 damaged app)

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

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.

Thanks for the kind words. Looking forward to seeing how devs will use it.

> specify a generic target and then having a documented manifest format sounds nice to me?

It worked this way in an earlier iteration. I just wanted to make it simpler. I'll probably circle back and re-enable some of the more custom setups.

It does allow to you generate the apps and installers locally, but they are still "connected" to the cloud (NPM) for downloading the actual jar files and performing updates.

> Similar to GP I wouldn't be trusting NPM with this kind of thing

Have there been some events that cast doubt on the trustworthiness of NPM? vs, say Github?

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.

All files related to it are kept in $HOME/.jdeploy

The observation that it downloaded 2 JREs (one for the installer and the other for the app) is a rough edge that will be fixed in an upcoming release. The reason is that the installer itself is an app that was bundled by jDeploy. It required a JRE, but didn't require JavaFX. When you, then launched the actual app, which was installed, it needed JavaFX, so couldn't use the JRE that was installed for the installer app, so it downloaded a JRE with JavaFX.

I will be optimizing this so that the "installer app" will try to use a JRE that meets both the installer requirements and app requirements so it only needs to download one JRE.

Hope that makes sense.

Here here! I sometimes pull out one of the old Swing books just for the enjoyment of nostalgia.

> I however, am not interested in using it due to the NPM aspect

Some people (here and elsewhere) have expressed similar sentiments about NPM. What would be your preferred alternative? Self hosted? Github releases?

Originally I built it to be self hosted, but NPM was just so darned easy to work with and made the process smoother, so I focused on that. NPM is really just a CDN in this context.

> 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.

Glad to hear! Please share them when you post them. Looking for more samples for the homepage.

> Second coming of JNLP it looks like

Yeah. JNLP always still felt a bit second class to me. The move to native bundles was, all in all, a good step, but the process was always too cumbersome.

Cool! Ping me when you get around to it. I'm still trying to put together some more samples for the homepage if you're willing to let me post them there.

> I spent so many hours fiddling with jlink and modules and so on.

Me too... Me too.

> 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.

> 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..).

I considered that. The approach I'm taking was inspired by the way that Chrome creates app bundles for PWAs.

> What happens when someone publishes some malware application using their wrapped and noterized installer

The installer application simply installs the app. It doesn't in itself run any of the app's code. The installed app doesn't need to be codesigned and notarized like it would if you had just downloaded it from in your web browser.

This works fine for many cases. A limitation is that apps built in this way can't be submitted to the app store. For that you would use jpackage or similar. But in most cases, this strategy is fine - and even better since it includes things like auto-updates.

> Can't you already do this with jpackage or graalvm to create native bundles?

With jpackage or graalvm you need a Windows machine to build your windows installer because it relies on 3rd party Windows tools for the installer. Likewise on Mac and Linux. Even worse, on Mac you need to Codesign and Notarize the app, which is painful every time.

> At least with jpackage you already get an installer, versioning and upgradeability.

With jDeploy, it will check for updates when the app launches, and will download them automatically, so your users are always on the latest version.

> Relying on npm seems a bit awkward.

1. npm solves a few problems here. By publishing to npm, the app is instantly available to be downloaded and installed by users.

2. Auto updating. The launcher will automatically check for updates on launch, and download them if any are found so that users are always working with your latest version.

I may add support for other CDNs - and originally I just had it so you self host. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish.

> I might suggest using native packages, especially on mac; something like a DMG or .package. > Relying on npm seems a bit awkward.

1. npm solves a few problems here. By publishing to npm, the app is instantly available to be downloaded and installed by users.

2. Auto updating. The launcher will automatically check for updates on launch, and download them if any are found so that users are always working with your latest version.

I may add support for other CDNs - and originally I just had it so you self host. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish.

> I might suggest using native packages, especially on mac; something like a DMG or .package

The trouble with DMG and .pkg is that they need to be codesigned and notarized individually - which means you need a Mac and an Apple Developer account. Using jDeploy you don't need a Mac, and you don't need to worry about codesigning. This is because the installer is already signed and notarized. This probably the biggest pain point that I wanted to solve with jDeploy.

The launcher, which is written in Go and C, is precompiled, so it can be reused in all apps. This means that, unlike jpackage, which requires you to build the Windows installer on Windows, the Mac installer on Mac, etc..., you can build for any platform from any platform.

The idea is to fulfill the promise of WORA all the way to deployment. Everything is built and configured in a cross-platform way, and then is deployed as first-class native bundles on each platform.

This is a passion project of mine to make it easier to deploy Java desktop apps. I'm very happy with the result, as IMO, the process is orders of magnitudes simpler than what we had before. Some features include:

- Native installers for Mac, Windows, and Linux

- Build native bundles for all platforms from any platform (e.g. You don't need Mac to make a Mac app. You don't need Windows to make a Windows app, etc..)

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

- Small installer bundle size (3mb compressed)

- No need to futz with Mac codesigning/notarization

- Instant download page so your users can download your app as soon as its published.

- Free, open source

Please take it for a spin, and let me know what you think.

Thanks. I like many aspects of their service description. The pricing per website, makes sense, but I obviously prefer the Dreamhost one price for unlimited sites model.

Thanks. This looks like exactly what I'm looking for.

Ya. I know it can be hard to justify all the work involved in watching on LaserDisc, when it's just so easy to dial it up on Plex. The first thing I did when I got it was digitize it, and copy it to Plex. But something about watching it on the real hardware, listening to the disc spinning, watching it switch sides A->B every 30 minutes, that transports me back to a simpler time.

This is the story of my quest to acquire the original theatrical version of the Star Wars trilogy on LaserDisc. I got more than I bargained for.

To use "blocking" code you must be running in a Java thread. You cannot "block" the main javascript thread. Generally all of our code runs on a Java thread. For JS events (which always occur on the main JS thread, I just wrap in new Thread(()->{...}).start();

The WASM port is experimental. The Javascript target produces better performance. For JVM languages it will always be the case that the Javascript target performance better than the WASM target, mostly because of GC. For the WASM port the developer wrote his own GC.