jpackage custom resources not found
mik3hall at gmail.com
Tue Jan 15 16:43:01 UTC 2019
> On Jan 15, 2019, at 10:35 AM, Andy Herrick <andy.herrick at oracle.com> wrote:
> On 1/15/2019 11:25 AM, Michael Hall wrote:
>>> On Jan 15, 2019, at 10:19 AM, Andy Herrick <andy.herrick at 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.
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.
More information about the core-libs-dev