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

[Andy Herrick]

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
>
>
>
>
>
>