jpackage custom resources not found

Andy Herrick andy.herrick at
Tue Jan 15 16:35:11 UTC 2019

On 1/15/2019 11:25 AM, Michael Hall wrote:
>> On Jan 15, 2019, at 10:19 AM, Andy Herrick <andy.herrick at> wrote:
>> On 1/15/2019 11:04 AM, Michael Hall wrote:
>>> java -version
>>> openjdk version "12-internal" 2019-03-19
>>> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7)
>>> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing)
>> This is the first jpackage EA build that was based on JDK12.
>> The second jpackage EA build is based on JDK13. (as will be any subsequent jpackage EA builds).
>> Real JDK12 builds will not have jpackage.  Even normal JDK13 builds will not have jpackage till the JEP is targeted and the sandbox code is then integrated into the mainline JDK.
> Yes, I had installed that version as well. The first EA.
> So removing the jdk-13 fell back to that one.
> ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version
> jpackage version 13-internal
> Shows the second EA jpackage can be explicitly invoked against a current jdk-12. But I understand it isn’t supported that way so why normally do it?

Actually, once jpackage is invoked the path is not used. jpackage itself 
will run with the jre it comes with.  Without -- runtime-image 
specified, jpackage will package the app with runtime image it comes 
with.  If --runtime-image is specified, it will package the app with the 
specified runtime.


>   Thanks for the additional information on the upcoming command availability.

More information about the core-libs-dev mailing list