Filling the Packager gap

Sverre Moe at
Thu Dec 13 18:25:07 UTC 2018

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos <johan.vos at>:

> Hi,
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> or to this backport)
> - Johan

Has anyone been able to use jpackager with bundle resources?
The jpackager says to put these on the class path
Using default package resource [menu icon]  (add package/linux/app.png to
the class path to customize)
Using default package resource [Menu shortcut descriptor]  (add
package/linux/app.desktop to the class path to customize)
Using default package resource [RPM spec file]  (add package/linux/app.spec
to the class path to customize)

I have mentioned on corejdk mailinglist that the help output should mention
how to do this.
The jpackager does not support any classpath argument. The old javapackager
did have an argument for setting classpath.
Editing the jpackager bash script to include "-cp
/path/to/project/build/deploy/" does not work.
Considering that jdk.packager is a java module, I even tried to add the
directory where package/linux is to the module-path.
--module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH}

It seems jpackager has been re-targeted for Java 13. I just hope it will
continue to be usable for package Java 11 applications. The backported
jpackager is working fine except for this resource problem.


More information about the openjfx-dev mailing list