jDeploy vs jpackage
When does it make sense to distribute your Java desktop app with jDeploy vs jpackage
Trying to decide how to deploy and distribute your Java desktop app? Not sure whether to use jDeploy or jpackage? This short article is meant to outline the differences as well as a few pros and cons of either tools.
What is jpackage?
jpackage is the official tool provided with OpenJDK for bundling your Java apps and native bundles. It will create app bundles for Mac, Windows, or Linux with an embedded Java runtime image. On Mac, it can produce either .pkg, .app, or .dmg bundles. Windows supports .msi installers, and Linux supports .deb and .rpm bundles.
It depends on platform native tools to create the bundles so you can only create bundles on the platform on which you are performing the build. E.g. If you’re running jpackage on Windows, you can’t generate a Mac bundle and vice versa.
Typically, when using jpackage, you would first create a Java runtime image using jlink. If you use Java’s module system in your app (JPMS), this will allow you to prune out portions of JavaSE that your app doesn’t need, resulting in a smaller bundle size.
Once you have your app bundle, you’ll need to sign it for the target platform and choose your distribution method. Common distribution methods include app stores, package managers, or just uploading it to S3 and offering it for download through your website. When distributing through the app stores, app updates are handled “automatically” for your users - or at least, they are made available to your users.
If you are distributing through your website, then you’ll need to provide your own update mechanism.
What is jDeploy?
jDeploy is an open source tool that allows you to build and deploy native app bundles for Mac, Windows, and Linux from any platform. It removes the most painful points from the app deployment process so that you can focus on your app and its features, and let jDeploy take care the app bundling and deployment.
When bundling an app with jDeploy, the first difference you’ll notice (vs jpackage) is that you can produce bundles for all platforms from any platform. It doesn’t depend on any native tooling at all - it’s pure Java.
The second thing you’ll notice is that the app bundle is much smaller than a typical app bundled by jpackage. ~3MB compressed vs ~75MB compressed. This is because the app bundle includes only a minimal launcher, and will download and install the appropriate Java runtime seamlessly when the app is launched.
The third thing you’ll notice is that jDeploy not only bundles your app, it deploys it as well - hence the name “jDeploy”. It can be configured to use either GitHub releases or npm for deployment. Users can download your app instantly using the provided download page on jdeploy.com, or, from GitHub releases directly.
You’ll probably notice quite a few other little differences when you deploy your first app, but the real “killer” feature is the “auto update”. If you deploy a new version of your app, then users who have already installed your app will automatically receive the update the next time they launch the app.
If you use GitHub for deployment with the jDeploy GitHub action, you can even generate updates automatically on each commit and tag. You can distribute separate versions of your app that are bound to a particular Git branch. E.g. You can have a “dev” and “stage” branch, where users who install the “dev” version of your app receive only updates from the “dev” branch, and users who install the “stage” version receive only update from the “stage” branch. Your “production” version, which you distribute to your users, would receive updates from actual versioned releases only.
When to use jpackage vs When to use jDeploy
If you want to distribute your app through the Mac or Windows app stores, then you should use jpackage, as jDeploy’s auto-update features don’t fit well with the app store distribution model.
In most other situations it is worth using jDeploy for its ease of deployment and auto-update features. Even if you do distribute your app through the app store, it may be useful to provide an alternative distribution using jDeploy for your beta users to make it easier to ship updates.
The low friction of jDeploy also makes it appropriate for developing and distributing ad-hoc internal utilities of PoC apps that you want to build and deploy quickly for feedback. Using the jDeploy IntelliJ plugin, it takes only a minute to create a new JavaFX or Swing project with a GitHub repository that automatically generates releases on each commit.
Getting Started
For more information about jDeploy, check out the jDeploy website.
Check out the “Samples” section to see a few example apps for a taste what the user experience is like.
Nice article, but when working inside a fairly locked down company there doesn't seem to be any good options.