RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)
andy.herrick at oracle.com
Mon Jan 28 17:56:41 UTC 2019
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
> 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
> 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
> 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
> 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.
More information about the core-libs-dev