1 Packaging Overview

The packaging tool jpackage enables you to generate installable packages for modular and non-modular Java applications. Platform-specific packages for Linux, macOS and Windows provide your users with a familiar way to install and launch your applications.

The simplest form of packaging takes a pre-built Java application as input and generates an installable package in a platform-dependent default format. The packaging tool generates a runtime for your application using the jlink command.

For applications that require more advanced capabilities, command line options are available for features such as the following:

• Provide a custom icon
• Install the application in a specific location
• Specify JVM options and application arguments to be used when launching the application
• Set file associations to launch the application when an associated file type is opened
• Launch the application from a platform-specific menu group
• Set up multiple launchers for the application
• Sign the bundle (macOS only)

For a description of jpackage and its options, see The jpackage Command in Java Development Kit Tool Specifications.

Topics:

• Packaging Pre-Reqs

• Application Preparation

• Java Runtime Requirements

Packaging Pre-Reqs

Application packages must be built on the target platform. The system used for packaging must contain the application, a JDK, and software needed by the packaging tool.

To package your application for multiple platforms, you must run the packaging tool on each platform. If you want more than one format for a platform, you must run the tool once for each format.

The following platforms and formats are supported with the required software:

• Linux: deb, rpm:

  • For Red Hat Linux, the rpm-build package is required.

  • For Ubuntu Linux, the fakeroot package is required.

• macOS: pkg, app in a dmg

  Xcode command line tools are required when the --mac-sign option is used to request that the package be signed, and when the --icon option is used to customize the DMG image.

• Windows: exe, msi

  WiX 3.0 or later is required.

Application Preparation

To package your application, you must first build it and create the necessary JAR or module files. Resources needed by your application must also be available on the system used for packaging.

The following application-related information and resources are used for packaging:

• JAR or module files for the application
• Application metadata, for example, name, version, description, copyright, license file
• Installation options, for example, shortcut, menu group, additional launchers, file associations
• Launch options, for example, application arguments, JVM options

As part of the packaging process, an application image based on the files in the input directory is created. This image is described in Generated Application Image. To test your application before creating an installable package, use the --type app-image option to create only the application image.

Generated Application Image

The packaging tool creates an application image based on the input to the tool.

The following example shows the application image created for a simple Hello World application for each platform. Files that are considered implementation details are subject to change and are not shown.

• Linux:

  myapp/
    bin/              // Application launchers
      HelloWorld
    lib/
      app/
        HelloWorld.cfg     // Configuration info, created by jpackage
        HelloWorld.jar     // JAR file, copied from the --input directory
      runtime/             // Java runtime image
  

• macOS:

  HelloWorld.app/
    Contents/
      Info.plist
      MacOS/               // Application launchers
        HelloWorld
      Resources/           // Icons, etc.
      app/
        HelloWorld.cfg     // Configuration info, created by jpackage
        HelloWorld.jar     // JAR file, copied from the --input directory
      runtime/             // Java runtime image
  

• Windows:

  HelloWorld/
    HelloWorld.exe       // Application launchers
    app/
      HelloWorld.cfg     // Configuration info, created by jpackage
      HelloWorld.jar     // JAR file, copied from the --input directory
    runtime/             // Java runtime image
  

The application image generated by the tool works for most applications. However, you can make changes before packaging the image for distribution, if needed.

Java Runtime Requirements

To eliminate the need for users to install a Java runtime, one is packaged with your applications. The packaging tool generates a runtime image based on the packages or modules that your application needs.

If no Java runtime image is passed to the packaging tool, then jpackage uses the jlink tool to create a runtime for the application. Runtime images created by the packaging tool do not contain debug symbols, the usual JDK commands, man pages, the src.zip file, or service bindings (see the Configuration class).

For non-modular applications composed of JAR files, the generated runtime image contains the same set of JDK modules that is provided to class-path applications in the unnamed module by the regular java launcher. The following example creates a self-contained Java application composed of one JAR file:

jpackage --name DynamicTreeDemo \
         --input . --main-jar DynamicTreeDemo.jar \
         --module-path $JAVA_HOME/jmods

For modular applications composed of modular JAR files and JMOD files, the generated runtime image contains the application's main module and the transitive closure of all of its dependencies. The following example creates a self-contained Java application composed of one module:

jpackage --name Hello --module-path mods \
         --module com.greetings/com.greetings.Main

To add additional modules, use the --add-modules option. The following examples add the java.logging module:

jpackage --name DynamicTreeDemo \
         --input . --main-jar DynamicTreeDemo.jar \
         --module-path $JAVA_HOME/jmods \
         --add-modules java.logging

jpackage --name Hello --module-path "mods:$JAVA_HOME/jmods" \
         --module com.greetings/com.greetings.Main \
         --add-modules java.logging

In JDK 25 and later, the generated runtime image doesn't include service bindings. You can add them with the --jlink-options option and passing it the --bind-services jlink option:

jpackage --name DynamicTreeDemo \
         --input . --main-jar DynamicTreeDemo.jar \
         --jlink-options --bind-services

jpackage --name Hello --module-path mods \
         --module com.greetings/com.greetings.Main \
         --jlink-options --bind-services

Note:

• If you don't specify the --jlink-options option, then, by default, the jpackage tool adds these jlink options: --strip-native-commands, --strip-debug, --no-man-pages, and --no-header-files.

• In JDK 25 and later, jpackage no longer includes service bindings in the runtime image that it creates. Prior to JDK 25, jpackage would include them. As a result, the generated runtime images produced by jpackage in JDK 25 and later might not include the same set of modules as it did in prior JDK releases.

  To include the same set of modules in the generated runtime image as in previous JDK releases, use the --jlink-options option and pass it the --bind-services jlink option in addition to the default jlink options that jpackage uses:

  jpackage [...] --jlink-options --strip-native-commands --strip-debug \
                 --no-man-pages --no-header-files --bind-services

The runtime image generated by the tool works for most applications. However, you can create a custom runtime to package with your application, if needed.