Create a new tool,
jpackager, for packaging Java run-time images and self-contained Java server or client applications.
Create a simple packaging tool, based on the existing
javapackager, to generate the following types of native packages:
The tool should provide the following features:
- Support for native packaging formats to give the end user a more natural installation experience
- Ability to launch applications with parameters that the developer specifies at packaging time
- Ability to launch applications via platform-specific menu groups, such as Start menu items on Windows
- Simple file associations for the application
- Packaging of Java applications in a manner acceptable to app stores
Developers should be able to access the tool either by running the
jpackager executable or by using the
- The following features of the
javapackagertool will not be supported:
- Java Web Start application support
- JavaFX-specific features
jdepsusage for determining required modules
- Ant plugin
- There will be no GUI for the tool. A command-line interface (CLI) is sufficient.
- There will be no support for cross compilation. For example, this means that in order to create Windows packages one must run
jpackageron Windows. The tool can depend upon platform-specific tools.
Application developers are accustomed to packaging up their applications in a format that can be installed or executed on their native platform. The existing packaging tool,
javapackager, is currently part of OpenJFX. It has been distributed with the Oracle JDK since JDK 8, and was enhanced in JDK 9 to enable bundling applications with custom run-time images. JavaFX, including
javapackager, will be removed in JDK 11, leaving a gap for developers now accustomed to using the
There is also a need for tool that supports packaging up a Java Runtime, such as a JDK or server JRE, that can be installed on a target system.
jpackager tool will fill this gap by providing the ability to create packages for applications or a server JRE. Since this will be a new tool, we will take the opportunity to clean up the existing
javapackager API and command-line interface to remove deprecated or unsupported options and to conform to JEP 293.
jpackager tool will be delivered in a new
jdk.packager module as part of the JDK. This new tool will be based on the existing
javapackager tool, with all features related to Java Web Start and JavaFX excluded. The command-line interface (CLI) will be reworked according to JEP 293: Guidelines for JDK Command-Line Tool Options. In addition to the command-line interface,
jpackager will be accessible via the ToolProvider API under the name
The tool will provide support for several formats of application "bundles" that include all necessary Java dependencies. The basic is an application image that is stored in a single directory in the filesystem and can include following:
- Application launcher
- Java run-time image
- Application resources (e.g.,
- Configuration files (e.g.,
This image can be redistributed as is, or as an installable package (for example,
dmg format). If a user does not specify a filesystem location during the installation process then the default location for the application will be the typical default for each platform (for example, on Linux it will be
/usr/bin). When the application is started, the launcher will read the configuration files and launch the embedded Java run-time image with the specified arguments.
If no custom run-time image is provided, the tool will run
jlink to create a server JRE as the runtime image for the package.
jpackager will perform the following steps to generate a package, given a Java run-time image:
- Create the application image including the following:
- the Java run-time image
- the native launcher
- the support files for both application and JRE command-line options
- the application configuration files and native resources
- Create the native package from the image (optional step)
- the application image
- support for signing packages
- package post-processing steps such as setting up file associations.
- Ability to specify JRE and application arguments at packaging time that will be used when launching the application
- Ability to set file associations (for example, to allow launching an application when a file with an associated suffix is opened)
- Option to specify update rules for installable packages (like rpm/deb)
The following "optional" features might be nice to include if there is time to do so:
- Additional types of native packages:
dmg(drag the app into the
- Multiple launchers (enables a suite of applications to be bundled in a single self-contained application package)
- Single vs multiple instance (prevents multiple instances of the application from launching)
- Ability to output (without executing) native packaging commands that developers can use as a starting point for addressing more complex needs. This could help developers that may want to add additional parameters to the native packaging commands or to package in formats not supported directly by the tool.