JavaPackager turns a jar into a native executable and an installer

The problem is the JRE on the user's machine

JavaPackager is described as a hybrid plugin for Maven and Gradle that packages Java applications as native Windows, macOS and GNU/Linux executables, and generates installers for them, with an optional customized JRE.

That optional bundled JRE is the reason the project exists. A Java application is normally distributed as a jar, and the jar assumes a JRE is already on the machine. For a server that assumption is fine. For a desktop tool distributed to non technical users on three operating systems, it is the central problem: the download is not the application, the download is the application plus a runtime, and the installation instructions are a support burden.

The plugin's answer is to make that runtime part of the artefact. The application ships as a native executable, which is what the user sees in their file manager and what the platform's own installer machinery knows how to install, update and uninstall, and the JRE can travel with it inside the package.

The project is published to Maven Central as io.github.javapackager, with the documentation at javapackager.github.io/JavaPackager. The licence is GPL 3.0.

The audience is therefore narrow and specific: a team with a Java application, a distribution channel to end users, and a decision to make about which operating systems to support.

2.0 changed the coordinates, and that is a breaking change

The README carries a warning box, and it is the first thing a returning user needs to know. Since 2.0.0 the coordinates are io.github.javapackager, and the warning says that covers the groupId, the Gradle plugin id and the Java packages. There is a dedicated upgrading guide in the documentation for the details.

That is three separate breakages in one release. A Maven build that referenced the old group and artifact has to change its plugin coordinates, a Gradle build that applied the plugin by its old id has to change that too, and any code that imported the plugin's Java classes directly has to change its imports, because the package names moved as well.

The timing is worth noting. The 2.0.0 release is dated 2026-10-10, the release candidate 2.0.0-rc1 is from 2026-10-04, and the previous version listed is 1.7.6 from 2024-06-30. So the major version arrives after a long gap, which is the normal pattern for a project that is stable but not fast moving, and it means the upgrade is a one off event rather than something you do every few months.

The README also states plainly that JavaPackager has been maintained for many years but that its maintainers have little time, and it asks for contributors to help with issues, reviews and documentation, pointing at a discussion thread. A project asking for maintainers is telling you something about its future, and it is worth weighing alongside the long release gap when you decide how much of your build to hang on it.

The same goal, expressed twice

The quick start gives both build systems, and they do the same thing with different syntax. For Maven, the plugin is declared with an execution bound to the package phase and the package goal, with the main class and the JRE bundling as configuration.

<plugin>
    <groupId>io.github.javapackager</groupId>
    <artifactId>javapackager</artifactId>
    <version>2.0.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>package</goal>
            </goals>
            <configuration>
                <mainClass>com.example.Main</mainClass>
                <bundleJre>true</bundleJre>
            </configuration>
        </execution>
    </executions>
</plugin>

The Gradle form applies a plugin by id and version, then opens a javapackager block for the configuration.

plugins {
    id 'io.github.javapackager' version '2.0.0'
}

javapackager {
    mainClass = 'com.example.Main'
}

In both cases the build is the ordinary one, mvn package or gradle package, and the plugin hooks into it.

mvn package

gradle package

The application and its installers are generated in target/ for Maven and build/ for Gradle. The Gradle example does not set bundleJre, while the Maven one does, which is a small difference between the two samples and worth checking against the documentation, which the README says contains every property, platform and guide.

Seven installer formats across three platforms

The format list is the clearest statement of scope: Inno Setup, MSI, DMG, PKG, DEB, RPM and AppImage, with an optional customized JRE.

Reading it by platform clarifies what the plugin is doing. On Windows there are two routes, Inno Setup for a script driven installer and MSI for the installer format Windows itself understands and that enterprise deployment tooling knows about. On macOS there is DMG, the disk image format, and PKG, the installer package format that the macOS installer system handles. On Linux there is DEB for Debian and Ubuntu, RPM for the Red Hat family, and AppImage, which is the runnable single file that needs no system integration at all.

The AppImage option is the interesting one for a team that wants to ship on Linux without getting a distribution to accept a package. The DEB and RPM routes are the ones that want a maintainer relationship with a distribution, because that is what makes updates work, and that is a cost the plugin does not remove.

The other axis is the runtime. A packaged application with a bundled JRE is large and self contained, and the user does not need Java installed. Without it, the executable is a launcher that expects a JRE to be present, which is smaller but puts the requirement back on the user.

Those two choices, the installer format and the runtime, are the two decisions a team really makes, and the plugin exists to make them configuration in the build file rather than a hand written script per platform. The documentation is where the full property list lives, since the README does not enumerate the options for each platform.

Real applications in the list, and a GPL licence to consider

The README keeps a table of applications packaged with JavaPackager, which is a more informative signal than a feature list. The entries are WePush, a bulk message sender for WeChat templates, SMS and email, MooTool, a developer tool set, bilibili-backup, a backup and restore tool for Bilibili accounts, RedisFX, a lightweight Redis GUI client built with JavaFX, RedisFront, a cross-platform Redis client built with Swing, and MooInfo, a system and hardware information viewer.

The pattern is instructive. These are small to medium desktop utilities built in Java, several of them with a Swing or JavaFX user interface, aimed at users who would not install a JRE themselves. That is exactly the profile the plugin serves, and it is worth noting that the table is presented as an illustration of the range rather than as a claim of support for those products.

The licence is GPL 3.0, with the file in the LICENSE path at the repository root. For a build plugin, the practical question is narrower than it is for a library, since the plugin runs at build time on your own machine and is not distributed with your application. If your organisation has a policy that treats GPL tooling as requiring review, that review is about your build environment rather than about what you ship.

For the artifact you do ship, the more relevant question is what you bundle. A bundled JRE is a third party runtime inside your installer, and the licence and update policy of that runtime are your responsibility rather than the plugin's, which is another reason to look at the documentation's guidance on the customized JRE before turning the option on.

Editorial conclusion

JavaPackager fits a team shipping a Java desktop or tool application to users who will not have a JRE installed, and who need a Windows installer and a Linux package from one build. It is the wrong tool for a server side application, where a jar and a service manager are the norm. Verify first which version you are on, because 2.0 changed the group id, the Gradle plugin id and the Java package names, and read the upgrading guide before you bump the version in a build that ships to users.

Frequently asked questions

Official sources

1. javapackager/JavaPackager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases