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