JPACKAGE(1)

πŸ“¦ version 17.0.21.0.3.u1, in arch rolling

πŸŽ€ JPACKAGE(1) β€” JDK Commands πŸŽ€

okay so welcome to jpackage(1) from the JDK Commands manual β€” this is the packaging bestie, and we're gonna make it make sense πŸ’…


NAME

jpackage β€” tool for packaging self-contained Java applications. 🫢

SYNOPSIS

jpackage [options]

options β€” Command-line options separated by spaces. See jpackage Options. ✨

DESCRIPTION

okay so picture this: the jpackage tool takes a Java application and a Java run-time image as input, and produces a Java application image that includes all the necessary dependencies. It can produce a native package in a platform-specific format, such as an exe on Windows or a dmg on macOS. πŸ”₯

🚨 Big caveat, bestie: each format must be built on the platform it runs on β€” there is no cross-platform support.

The tool has options that allow packaged applications to be customized in various ways. slay. πŸ’…


πŸ’– JPACKAGE OPTIONS πŸ’–

πŸŽ€ Generic Options:

  • @filename β€” Read options from a file. This option can be used multiple times. πŸ“„
  • --type or -t <type string> β€” The type of package to create. Valid values are: {"app-image", "exe", "msi", "rpm", "deb", "pkg", "dmg"}. If this option is not specified a platform dependent default type will be created. 🎁
  • --app-version <version> β€” Version of the application and/or package. 🏷️
  • --copyright <copyright string> β€” Copyright for the application. ©️
  • --description <description string> β€” Description of the application. πŸ“
  • --help or -h β€” Print the usage text with a list and description of each valid option for the current platform to the output stream, and exit. πŸ™‹β€β™€οΈ
  • --icon <icon file path> β€” Path of the icon of the application package (absolute path or relative to the current directory). πŸ–ΌοΈ
  • --name or -n <name> β€” Name of the application and/or package. ✨
  • --dest or -d <output path> β€” Path where generated output file is placed. Defaults to the current working directory. (absolute path or relative to the current directory). πŸ“
  • --temp <directory path> β€” Path of a new or empty directory used to create temporary files (absolute path or relative to the current directory). If specified, the temp dir will not be removed upon the task completion and must be removed manually. If not specified, a temporary directory will be created and removed upon the task completion. 🧹
  • --vendor <vendor string> β€” Vendor of the application. 🏒
  • --verbose β€” Enables verbose output. πŸ—£οΈ
  • --version β€” Print the product version to the output stream and exit. πŸ”’

🧚 Options for creating the runtime image:

  • --add-modules <module name> [,<module name>...] β€” A comma (",") separated list of modules to add. This module list, along with the main module (if specified) will be passed to jlink as the --add-module argument. If not specified, either just the main module (if --module is specified), or the default set of modules (if --main-jar is specified) are used. This option can be used multiple times. 🧩
  • --module-path or -p <module path>... β€” A File.pathSeparator separated list of paths. Each path is either a directory of modules or the path to a modular jar, and is absolute or relative to the current directory. This option can be used multiple times. πŸ›£οΈ
  • --jlink-options <jlink options> β€” A space separated list of options to pass to jlink. If not specified, defaults to "--strip-native-commands --strip-debug --no-man-pages --no-header-files". This option can be used multiple times. βš™οΈ
  • --runtime-image <directory path> β€” Path of the predefined runtime image that will be copied into the application image (absolute path or relative to the current directory). If --runtime-image is not specified, jpackage will run jlink to create the runtime image using options specified by --jlink-options. πŸ–₯️

🌸 Options for creating the application image:

  • --input or -i <input path> β€” Path of the input directory that contains the files to be packaged (absolute path or relative to the current directory). All files in the input directory will be packaged into the application image. πŸ“¦

πŸ¦‹ Options for creating the application launcher(s):

  • --add-launcher <launcher name>=<file path> β€” Name of launcher, and a path to a Properties file that contains a list of key, value pairs (absolute path or relative to the current directory). The keys "module", "main-jar", "main-class", "arguments", "java-options", "app-version", "icon", "linux-app-category", "linux-app-release", and "win-console" can be used. These options are added to, or used to overwrite, the original command line options to build an additional alternative launcher. The main application launcher will be built from the command line options. Additional alternative launchers can be built using this option, and this option can be used multiple times to build multiple additional launchers. πŸš€
  • --arguments <main class arguments> β€” Command line arguments to pass to the main class if no command line arguments are given to the launcher. This option can be used multiple times. πŸ’¬
  • --java-options <java options> β€” Options to pass to the Java runtime. This option can be used multiple times. β˜•
  • --main-class <class name> β€” Qualified name of the application main class to execute. This option can only be used if --main-jar is specified. 🧠
  • --main-jar <main jar file> β€” The main JAR of the application; containing the main class (specified as a path relative to the input path). Either --module or --main-jar option can be specified but not both. πŸ«™
  • --module or -m <module name>/<main class>] β€” The main module (and optionally main class) of the application. This module must be located on the module path. When this option is specified, the main module will be linked in the Java runtime image. Either --module or --main-jar option can be specified but not both. 🧱

πŸͺŸ Platform dependent option for creating the application launcher:

Windows platform options (available only when running on Windows):

  • --win-console β€” Creates a console launcher for the application, should be specified for application which requires console interactions. πŸ–₯️

macOS platform options (available only when running on macOS):

  • --mac-package-identifier <ID string> β€” An identifier that uniquely identifies the application for macOS. Defaults to the the main class name. May only use alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters. 🍎
  • --mac-package-name <name string> β€” Name of the application as it appears in the Menu Bar. This can be different from the application name. This name must be less than 16 characters long and be suitable for displaying in the menu bar and the application Info window. Defaults to the application name. 🌟
  • --mac-package-signing-prefix <prefix string> β€” When signing the application package, this value is prefixed to all components that need to be signed that don't have an existing package identifier. πŸ”
  • --mac-sign β€” Request that the bundle be signed. ✍️
  • --mac-signing-keychain <keychain name> β€” Name of the keychain to search for the signing identity. If not specified, the standard keychains are used. πŸ”‘
  • --mac-signing-key-user-name <team name> β€” Team or user name portion in Apple signing identities. πŸ‘₯
  • --mac-app-store β€” Indicates that the jpackage output is intended for the Mac App Store. πŸ›οΈ
  • --mac-entitlements <file path> β€” Path to file containing entitlements to use when signing executables and libraries in the bundle. πŸ“œ
  • --mac-app-category <category string> β€” String used to construct LSApplicationCategoryType in application plist. The default value is "utilities". πŸ—‚οΈ

🎁 Options for creating the application package:

  • --about-url <url> β€” URL of the application's home page. 🌐
  • --app-image <directory path> β€” Location of the predefined application image that is used to build an installable package (absolute path or relative to the current directory). See create-app-image mode options to create the application image. πŸ–ΌοΈ
  • --file-associations <file path> β€” Path to a Properties file that contains list of key, value pairs (absolute path or relative to the current directory). The keys "extension", "mime-type", "icon", and "description" can be used to describe the association. This option can be used multiple times. πŸ”—
  • --install-dir <directory path> β€” Absolute path of the installation directory of the application (on macos or linux), or relative sub-path of the installation directory such as "Program Files" or "AppData" (on Windows). πŸ“‚
  • --license-file <file path> β€” Path to the license file (absolute path or relative to the current directory). πŸ“„
  • --resource-dir <directory path> β€” Path to override jpackage resources (absolute path or relative to the current directory). Icons, template files, and other resources of jpackage can be over-ridden by adding replacement resources to this directory. 🎨
  • --runtime-image <directory path> β€” Path of the predefined runtime image to install (absolute path or relative to the current directory). Option is required when creating a runtime installer. 🧰

πŸ’» Platform dependent options for creating the application package:

Windows platform options (available only when running on Windows):

  • --win-dir-chooser β€” Adds a dialog to enable the user to choose a directory in which the product is installed. πŸ“
  • --win-help-url <url> β€” URL where user can obtain further information or technical support. πŸ†˜
  • --win-menu β€” Request to add a Start Menu shortcut for this application. πŸͺŸ
  • --win-menu-group <menu group name> β€” Start Menu group this application is placed in. πŸ“Œ
  • --win-per-user-install β€” Request to perform an install on a per-user basis. πŸ‘€
  • --win-shortcut β€” Request to create a desktop shortcut for this application. πŸ–±οΈ
  • --win-shortcut-prompt β€” Adds a dialog to enable the user to choose if shortcuts will be created by installer. ❓
  • --win-update-url <url> β€” URL of available application update information. πŸ”„
  • --win-upgrade-uuid <id string> β€” UUID associated with upgrades for this package. πŸ†”

🐧 Linux platform options (available only when running on Linux)

Okay bestie, these ones are Linux-only β€” if you're not on Linux, you can literally skip this whole list, no FOMO. 🐧✨

  • --linux-package-name &lt;package name&gt; β€” the name your Linux package gets. Yep, she's naming her baby. Defaults to the application name, so if you don't say anything she just reuses the app's own name. πŸ’…
  • --linux-deb-maintainer &lt;email address&gt; β€” the maintainer listed in the .deb bundle. Drop that email, claim your package, main character energy. πŸ“§
  • --linux-menu-group &lt;menu-group-name&gt; β€” the menu group this application gets placed in. She needs to know where to sit at lunch. 🍱
  • --linux-package-deps β€” the required packages or capabilities for the application. It's giving "what she needs to thrive." πŸ”₯
  • --linux-rpm-license-type &lt;type string&gt; β€” the type of the license, and for real it goes into the "License: <value>" field of the RPM .spec. πŸ“œ
  • --linux-app-release &lt;release string&gt; β€” the Release value of the RPM <name>.spec file, or the Debian revision value of the DEB control file. Two moods, one flag. πŸŽ€
  • --linux-app-category &lt;category string&gt; β€” the Group value of the RPM <name>.spec file, or the Section value of the DEB control file. Again: two moods, one flag, she's flexible like that. πŸ¦‹
  • --linux-shortcut β€” creates a shortcut for the application. Convenience icon, we love to see it. ⭐

πŸ“ JPACKAGE EXAMPLES πŸ“

Bestie this is the part you actually came for, ngl. Reference bars, everyone. πŸ”₯

Generate an application package suitable for the host system:

For a modular application:

jpackage -n name -p modulePath -m moduleName/className

For a non-modular application:

jpackage -i inputDir -n name \
    --main-class className --main-jar myJar.jar

From a pre-built application image:

jpackage -n name --app-image appImageDir

Generate an application image:

For a modular application:

jpackage --type app-image -n name -p modulePath \
    -m moduleName/className

For a non-modular application:

jpackage --type app-image -i inputDir -n name \
    --main-class className --main-jar myJar.jar

To provide your own options to jlink, run jlink separately β€” yes, separately, don't try to sneak them in here, she will notice: πŸ™ˆ

jlink --output appRuntimeImage -p modulePath \
    --add-modules moduleName \
    --no-header-files [<additional jlink options>...]
jpackage --type app-image -n name \
    -m moduleName/className --runtime-image appRuntimeImage

Generate a Java runtime package:

jpackage -n name --runtime-image <runtime-image>

Fr fr, go build something iconic with this. Your packages are gonna eat. πŸ‘‘

🌸 That's the whole page, bestie! This gem comes straight out of JDK 17, dated 2021, and it lives at section JPACKAGE(1) of the manual β€” which honestly is the only citation you need. Now go forth and jpackage responsibly. πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from