RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)
Alan.Bateman at oracle.com
Sun Jan 27 09:55:40 UTC 2019
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
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
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
More information about the core-libs-dev