On 2/24/2020 4:32 PM, Michael Hall wrote:

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.

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.

/Andy


Reply via email to