Comments on jpackage (JEP 343)

Andy Herrick andy.herrick at
Thu Sep 5 11:57:55 UTC 2019

Thank you very much for the detailed feedback.

see inline for Change Requests created or associated with each point .


On 9/3/2019 2:58 PM, mark.reinhold at wrote:
> I spent some time last week playing with the jpackage tool, using build
> 14-jpackage+1-35 from
> Overall, I can see that you’ve made good progress, but there’s still some
> work to be done.  I’ll start with high-level comments and questions, and
> then comment on my experience using the tool on Debian and then macOS.
> High-level comments/questions
>    - It’s good that you’re publishing EA builds, but I haven’t seen very
>      much feedback from those builds.  It may be better to propose this as
>      an experimental feature when it’s ready to target.  That would give
>      you the freedom to improve it incompatibly over one or two release
>      cycles before you commit to a final version.

We like the suggestion to release as an experimental feature.

see: JDK-8230649 <>

>    - The tool still generates an image by default, rather than a package.
>      This will surprise many users, especially those who just want to do
>      something simple and straightforward.  The least-surprising default
>      behavior would be to generate a package of the type most suitable for
>      the current platform.  An option to generate just an image would be
>      fine, for those who want to tweak it before the actual packaging
>      step, but that shouldn’t be the default.
>    - Related to the previous point, I should only have to specify the
>      `--package-type` option if I want something other than the default
>      for the current platform.

We will add "app-image" as an explicit type and change the 
--package-type default to be type most suitable for the current platform.

see: JDK-8230519 <>

>    - The tool assumes that the application being packaged will have a GUI.
>      This isn’t surprising, considering its heritage, but as a consequence
>      it always produces packages that perform GUI-specific actions, such
>      as installing icons and desktop-menu entries.  If I’m just packaging
>      a command-line tool then these are unnecessary, and supporting them
>      can pull in lots of additional dependencies (e.g., a ton of Perl
>      scripts on Debian).  Consider adding an option (`--gui`?) so that
>      the user can indicate when an application is to be installed for
>      graphical use.

For giving the developer the control of shortcuts we have created : 
JDK-8229779 <>

If an application does not request shortcut(s) there should be no need 
for gui code.
>    - The `--output`/`-o` option is confusing.  It doesn’t name the output
>      itself, but rather a directory into which the single item of output
>      will be placed.  Typing `-o .` all the time is just annoying.  It’d
>      be more logical to rename this option to `--dest`/`-d` and to make it
>      optional, with a default value of `.`.

We will change name of option and default as suggested

see: JDK-8230521 <>

>    - If my app is modular, and my main module has a version string, then
>      it’d be nice for that to be used as the package version unless a
>      specific version is specified on the command line.
see: JDK-8230651 <>
>    - Terminology: For Linux we generally speak of “packages” rather than
>      “bundles.”  Rename `--linux-bundle-name` to `--linux-package-name`.
this will be fixed as part of: JDK-8230522 
>    - The `--temp-root` option could be shortened to `--temp`.
see: JDK-8230522 <>
>    - Periods at the ends of error messages are unsightly and unnecessary.
>      We don’t use them in other JDK tools.  Please remove them.
This is also included in: JDK-8230522 
>    - It’d be nice to have an option that displays the programs being run
>      by the tool, in a form that can easily be cut-and-pasted into a
>      script for those who need to do a lot of customization.  The current
>      verbose output shows (at least some of) this information, but in a
>      difficult-to-use format.
see:JDK-8230652 <>
>    - What’s the rationale for copying the entire “input” directory as-is?
>      Why is its structure important?  Couldn’t you just as well limit this
>      to a single directory full of JAR files?
After discussion , I will look for use case where this existing behavior 
is desirable.
> Comments on Debian packaging

All of the below comments on Debian packaging  are reflected in 
JDK-8230507 <>

They may or may not be split up into individual CR's as they are addressed.

>    - On a Debian machine I tried to create a package for a trivial,
>      two-module application using the command
>        $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n hello
>      which gave me the error message
>         Bundler DEB Installer skipped because of a configuration problem: java.lang.NullPointerException.
>      (Side note: This message is confusing since the tool is creating a
>       Debian package, not an “installer.”)
>    - On a hunch, I specified a main application class:
>        $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello
>      and that created `hello_1.0-1_amd64.deb`.  It shouldn’t have been
>      necessary to specify a main class since the main module does have a
>      `ModuleMainClass` attribute in its module descriptor.
>    - The resulting package does not depend upon any others, i.e., the
>      `Depends:` line in its control file is empty.  This can’t possibly be
>      right, since the embedded JDK depends on many system libraries for
>      proper operation (`libc`, `libfreetype`, `libpthread`, etc.).
>    - The resulting package would install into `/opt/hello`, as expected,
>      but the `/opt/hello/bin` directory would contain not just the `hello`
>      application launcher but also `hello.desktop`, `hello.png`, and
>      ``.  These aren’t appropriate for a `bin` directory
>      and should be placed elsewhere, most likely `/opt/hello/lib`.
>    - The resulting package would install `/opt/hello/app` and
>      `/opt/hello/runtime` directories.  These are not strictly forbidden
>      by the Linux FHS [1], but it’d be better to put both of them under
>      `/opt/hello/lib`, per convention.
>    - The resulting package does not contain the normal `java` launcher.
>      It’d be helpful to retain this (in `runtime/bin/java`, not in the
>      app’s `bin` directory) for diagnostic purposes.  It’s not large.
>    - The resulting package would install the copyright file into
>      `/usr/share/doc/hello/copyright`, which is wrong -- a package that
>      installs into `/opt` should never touch anything under /usr [1].  This
>      file should be at `/opt/hello/share/doc/copyright`.
>    - I attempted to install the package on a fresh Ubuntu 18.04 machine:
>          # dpkg -i hello-1.0.deb
>          Selecting previously unselected package hello.
>          (Reading database ... 135670 files and directories currently installed.)
>          Preparing to unpack hello-1.0.deb ...
>          Unpacking hello (1.0) ...
>          Setting up hello (1.0) ...
>          Adding shortcut to the menu
>          /var/lib/dpkg/info/hello.postinst: 25: /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found
>          dpkg: error processing package hello (--install):
>           installed hello package post-installation script subprocess returned error exit status 127
>          Errors were encountered while processing:
>           hello
>          mr-dev # uname -a
>          Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>          mr-dev # cat /etc/lsb-release
>          DISTRIB_ID=Ubuntu
>          DISTRIB_RELEASE=18.04
>          DISTRIB_CODENAME=bionic
>          DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
>          #
>      Apparently the package should depend upon `xdg-utils`, so that its
>      post-install script can find `xdg-desktop-menu`.  Even better,
>      though, would be for this trivial non-graphical application not to
>      depend upon any desktop utilities, per my comment above.
>    - Installing the package succeeded despite the above error.  I was
>      successfully able to run my trivial application.  Yay!
>    - Then I tried to uninstall it:
>          mr-dev # dpkg --remove hello
>          (Reading database ... 135923 files and directories currently installed.)
>          Removing hello (1.0) ...
>          Removing shortcut
>          /var/lib/dpkg/info/hello.prerm: 25: /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found
>          dpkg: error processing package hello (--remove):
>           installed hello package pre-removal script subprocess returned error exit status 127
>          Errors were encountered while processing:
>           hello
>          mr-dev #
>      I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still
>      didn’t work:
>          mr-dev # dpkg --remove hello
>          (Reading database ... 136878 files and directories currently installed.)
>          Removing hello (1.0) ...
>          Removing shortcut
>          xdg-desktop-menu: No writable system menu directory found.
>          dpkg: error processing package hello (--remove):
>           installed hello package pre-removal script subprocess returned error exit status 3
>          Errors were encountered while processing:
>           hello
>          mr-dev #
>      I eventually figured out how to create a fake writable system menu
>      directory and was then able to remove the package.
>    - The `--linux-deb-copyright` option is confusing.  Its description
>      should mention that if this option is specified then the `--license`
>      option is, so far as I can tell, ignored.
>    - The `--identifier` option appears to have no use for Debian packages.
>      Perhaps this option should be package-type specific?  Or at least its
>      description should mention that it’s irrelevant to Debian packages.
>    - I tried to create a package that would install into the `/usr`
>      hierarchy by adding `--install-dir /usr` to the above command line.
>      The resulting package would create a `/usr/hello` directory, with
>      `app`, `bin`, and `runtime` directories under that.  That’s not
>      right.  To install an application in the `/usr` hierarchy its command
>      should go into `/usr/bin`, and libraries and other files should go
>      into `/usr/lib/$APPNAME`, and documentation and copyright files
>      should go into `/usr/share/doc/$APPNAME`.
>    - Many of the above observations could also apply to RPM packages, but
>      I haven’t checked.
> Comments on macOS packaging
>    (Warning: I’m not an expert macOS developer!)
>    - On a macOS machine (10.13.6) I tried to create a dmg package:
>        $ jpackage -o . --package-type dmg -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello
>      which gave me the error message
>        Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC, /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns] in unspecified directory output: xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
>      although it exited with status 0 and did produce a valid `.dmg` file.
>      I suppose I’m missing some development tools?  If so then please
>      document that dependency, and if possible issue a more helpful error
>      message that tells the user what they need to install.
see: JDK-8230653 <>
>    - It’d be nice if the resulting `.dmg` file, when opened, were to show
>      an icon for the Applications folder and an arrow pointing to that
>      from the app icon, so that the user can drag it across.  Almost all
>      `.dmg` files that I’ve seen do this.
see: JDK-8230654 <>
> - Mark
> [1]

Again, thanks for the detailed feedback.


More information about the core-libs-dev mailing list