On 1/15/2019 11:25 AM, Michael Hall wrote:
On Jan 15, 2019, at 10:19 AM, Andy Herrick <andy.herr...@oracle.com> 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.
/Andy
Thanks for the additional information on the upcoming command availability.
