jpackage current status

Andy Herrick andy.herrick at
Mon Feb 24 22:07:19 UTC 2020

On 2/24/2020 4:32 PM, Michael Hall wrote:
>> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth <kevin.rushforth at> wrote:
>> On 2/24/2020 12:31 PM, Michael Hall wrote:
>>>> On Feb 24, 2020, at 1:48 PM, Michael Hall <mik3hall at> wrote:
>>>>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth <kevin.rushforth at> 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.

now you can build runtime that has the tools like I do here:

> $JDK_HOME/bin/jlink --bind-services --output mods.runtime 
> --add-modules me.mymodule --module-path '../input-mods/mods'
(../input-mods/mods has my app in me.mymodule)

then in app you can find any of the tools by using 
System.getProperty("java.home") and looking in "bin" subdir.

So in the app you can refer to any of the tools by their full path.

My proposed addition of --jlink-options jpackage option would only make 
the first step unnecessary.


More information about the core-libs-dev mailing list