On 1/27/2019 4:55 AM, Alan Bateman wrote:
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.
I filed JDK-8217902 <https://bugs.openjdk.java.net/browse/JDK-8217902>
to investigate if we can make the layout the same on Mac as it is on
Linux and Windows. (otherwise we need to update the JEP)
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).
you should not need to specify --class, if the main-jar has a Main-Class
manifest entry this is a bug filed as:JDK-8217791
<https://bugs.openjdk.java.net/browse/JDK-8217791>
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?
still need to investigate this.
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
this is also a bug (related to JDK-8217902
<https://bugs.openjdk.java.net/browse/JDK-8217902>) I will add that to
the description.
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.
looking into this as part of: JDK-8217894
<https://bugs.openjdk.java.net/browse/JDK-8217894>
/Andy
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
