RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

[Alan Bateman]

On 11/01/2019 19:41, Andy Herrick wrote:
> This is the second update to the Request For Review of the 
> implementation of the Java Packager Tool (jpackager) as described in 
> JEP 343: Packaging Tool 
> <https://bugs.openjdk.java.net/browse/JDK-8200758>
I've started to play with the latest EA build, trying to figure it out 
in conjunction with the current wording in JEP 343.

I think the description/definition of "application image" needs to be 
beefed up. The current JEP doesn't reference JEP 220 and it's not 
immediately obvious how they relate. The HelloWorld example in the JEP 
shows the runtime next to an app directory but this doesn't match what I 
am seeing when I use `jpackage create-image`. Instead I see the java 
runtime is generated into PlugIns/Java.runtime. It's not clear why there 
is a "PlugIns" directory.

Can we do anything about simple cases where the application is a single 
executable JAR? When I use `jpackage create-image` for such cases then 
I'm forced to provide a directory to --input and  the main class to 
--class, neither of these options should be needed for simple cases like 
this, esp. when the tool also has --main-jar (which might need to be 
renamed to be consistent with other tools).

When I use `jpackage create-image` then it creates an embedded run-time 
image that is missing a lot of modules. For example, if my applications 
is indirectly using sun.misc.Unsafe, as some libraries do, then it will 
fail at run-time because the jdk.unsupported module is not included. The 
examples I tried were also missing java.sql, java.net.http and several 
more. Is this a bug or a relic from the old javapackager tool?

The JEP suggests that the tool can create a native launcher but it's not 
immediately obvious how to do that. An example in the JEP would be 
useful to have. I did get it working with `--secondary-launcher` but 
that is a really strange option. I wonder if this could be renamed to 
`--launcher` and also its input changed to be closer to the equivalent 
in jlink. I also wonder if it would be saner to have the properties 
specified directly to the option rather than in another properties file.

I also tried `jpackage create-installer`. When I specify `--app-image` I 
assumed I could specify an application image that I created previously 
`jpackage create-image` but it doesn't like that. The error for this 
usage is:
Error: App image directory "myimage" is invalid and does not contain 
"app" and/or "runtime" sub-directories

Are you planning to keep `jpackage create-jre-installer`? I can't tell 
if this is intended to be renamed or not but I think it would be 
confusing to have "JRE" in the name of CLI options. Also it's not clear 
what "jre-name" means. I think it would be saner to simplify this to 
allow an installer be created for a given run-time image, never the 
runtime that the jpackage tool is running on.

That's all I have for now. I see there is a lot of feedback and issues 
being tracked so I'll try it again once the implementation is a bit 
further along.

-Alan