> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
> wrote:
>
>
>
> On 2/24/2020 12:31 PM, Michael Hall wrote:
>>
>>> On Feb 24, 2020, at 1:48 PM, Michael Hall <mik3h...@gmail.com> wrote:
>>>
>>>
>>>
>>>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth <kevin.rushfo...@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.
