> On Jan 15, 2019, at 10:35 AM, Andy Herrick <[email protected]> wrote:
>
>
> On 1/15/2019 11:25 AM, Michael Hall wrote:
>>> On Jan 15, 2019, at 10:19 AM, Andy Herrick <[email protected]> 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.
>
Thats interesting too. How does it manage to do that, to run with the JRE it’s
packaged with if the command is invoked command line by absolute path? If
nothing has been done to make the wrapping JDK an available JRE/JDK? Not in
JavaVirtualMachines, no JAVA_HOME set, no JRE set up at all.
