jpackage current status
Michael Hall
mik3hall at gmail.com
Mon Feb 24 21:32:18 UTC 2020
> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
>
>
> On 2/24/2020 12:31 PM, Michael Hall wrote:
>>
>>> On Feb 24, 2020, at 1:48 PM, Michael Hall <mik3hall at gmail.com> wrote:
>>>
>>>
>>>
>>>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>>>
>>>> Since your ToolProvider-based program doesn't explicitly require jdk.incubator.jpackage, it won't be in the module graph. It should work fine if you run with:
>>>>
>>>> $ java --add-modules jdk.incubator.jpackage ...
>>>>
>>> I’m not understanding the module subtleties yet but yes that does work command line. Other than -add-modules into the runtime are there any special considerations for using it from an application?
>> Ah, the obvious. Same solution for application also works. I can programmatically invoke jpackage with this.
>
> Good.
>
>>> I am still wondering for the application embedded runtime exec not finding linked native commands if this is expected not to work or is considered an issue?
>>>
>> This remains a question for me. Should Runtime exec find the native commands included with an application embedded JRE? It currently doesn’t seem to on OS X.
>
> Unless that JRE's bin directory is in your PATH, I wouldn't expect it to find it.
>
OK, ToolProvider seems like it would be a preferred api. But unless someone figures out how to get the bin directory searched I wouldn’t see any point in having native commands included ever.
Maybe the enhancement Andy mentioned for this a while back might address this?
A thought. I now have no need to.
More information about the core-libs-dev
mailing list