We’ve gone from zero to (first) mission accomplished in nine short months. The initial vision for jDeploy was to make it painless to deploy Java desktop applications and their updates to users. This involved several pieces that had to work together in concert to create a smooth experience for users.
A launcher. I needed to build a native launcher for Windows, Mac, and Linux that would automatically download the app and updates on launch, as well as installing an appropriate JVM if required.
A bundler. I needed to create tools to bundle a Java app as a native app for each desktop platform, using the jDeploy launcher.
An install wizard. I needed to build a GUI installation wizard that would install the app on the user’s computer.
Authoring Tools. I needed to develop authoring tools for configuring and building your native apps on the desktop.
Distribution Channel. I needed to set up a distribution channel host the apps and their updates. The MVP release used npm only, but the plan was to add more options for this as time goes on.
A web-based Download Page. This was optional but I thought it really helped for making the process seamless. If you want to deploy your app, you will need a download page - so why not make one that works out of the box.
All of these core features were completed for the initial release.
Launching with a Bang
I announced jDeploy on HackerNews on February 15th, and it attracted quite a bit of interest, even making it to the front-page for a few hours.
A couple of weeks later, on March 1st, I started this newsletter, and the next day, I published The Decline and Fall of Java on the Desktop Part 1 (1999-2005), in which I reminisced about the glory days of Java on the desktop and expressed my desire to make it a more compelling environment for desktop development. This article was also well-received, reaching the HackerNews front page briefly as well.
In March and April, I posted new articles weekly with topics ranging from general Java desktop application development, to announcements about new jDeploy features and releases.
Slowing Down For a While
Due to family obligations and my day job, I took a break from posting to the newsletter for the next several months, but jDeploy was still under active development, and very much on my mind. jDeploy had already fulfilled my original vision, but there were still many areas that could be improved - e.g. enterprise-level features.
GitHub Actions and Releases Support
In the past month, I have spent a lot of time again developing jDeploy in preparation for the 4.0 release, now in beta. This includes many improvements, but the flag-ship feature is Github integration - the ability to deploy your app using Github releases instead of npm. This also includes a shiny new Github action that can be added to your workflows to automatically generate native installers for each release.
Learn more about publishing to Github in the Developer Guide.
After adding the Github action for releases, I realized there was an opportunity to go further, and create releases that track changes to a particular branch. E.g. You can create a version of your app that tracks all changes to the “master” branch, and a different version that tracks changes to a “dev” branch. Then your app will automatically be kept up to date with changes in the branch.
This all depends on the Github action being run on each commit.
For those of you using JavaFX, I decided to make things even easier by creating a JavaFX starter template on GitHub that gives you a starting point for a JavaFX app that has the Github workflows set up already so that your native installers are generated for each release, and for each commit.
What about Private Repositories?
This all worked great, but there was still one caveat when hosting on GitHub. It only worked for public repositories. This is because the app’s launcher needs to be able to download metadata from the GitHub release on launch (e.g. to download updates), and this wouldn’t be possible on a private repo (without embedding credentials into the launcher, which wouldn’t be great for security). I worked around this limitation by adding a “target_repository” parameter to the GitHub action to allow you to publish releases to a different repository. The idea is for you to set up a separate, dedicated public repository for your releases, and keep your “sources” in a private repository.
Learn more about publishing from private repositories in the developer guide.
Command-line Installation Snippet
One other feature that I quietly slipped in was the ability to launch the installer for your app directly from the command-line. Rather than downloading the installer Zip/Tar file, extracting that, and then double-clicking the installer, you can just copy and paste a snippet into your Terminal app (on Mac, Windows, or Linux), and have it launch directly that way.
It saves a few clicks if you’re comfortable in the command-line. This is especially nice on Linux since, at least Gnome, doesn’t let you double-click to open the installer. You need to run it on the command-line anyways.
What will 2023 Bring?
2023 is still a question mark. There are many directions I could go, but it will depend on supply and demand. How much demand is there for these features, and how much time do I have to supply them.
Some features that are “next” on my list:
Self-hosting. I.e. not hosting on npm or GitHub, but rather, on your own site, or on something like S3.
Private distribution. E.g. Require your users to have a license key in order for your app to work.
Service management. I.e. Adding support for managing the installation of companion windows, linux, or Mac background services with your app.
If you have feature suggestions, please share, either in the comments here, in the GitHub discussion forum.
For the newsletter, I will continue writing articles on general Java desktop development topics as I am inspired. There is also a backlog of features in jDeploy that I have yet to write about here - so there could be a few “how to” articles on the way also.
Thank you for your interest in this news letter and project. Merry Christmas and Happy New Year!
-Steve
Hi, will you continue with the grat series about Java Decline and Fall? Very interesting, I would be happy to read part 3!