Draft JEP proposal: JDK-8200758: Packaging Tool

[Alan Bateman]

On 31/05/2018 01:10, Kevin Rushforth wrote:
> I would like to propose the following Draft JEP [1] for discussion.
>
> JDK-8200758: Packaging Tool
>
> This is intended as a JDK-scope replacement for the existing 
> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle 
> JDK releases), and was delivered as part of the JavaFX build. The 
> javapackager tool has been removed from Oracle JDK 11 along with the 
> removal of JavaFX.
>
> Comments on this JEP are welcome. It is currently not targeted for a 
> specific release, but we are aiming for JDK 12.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>
I read through the draft.

The Goals and Non-Goals looks very reasonable.

The Summary includes "self-contained Java Server ... applications" but 
the JEP doesn't say too much about that part. Can we assume it can be 
started and stopped with /etc/init.d or equivalent scripts, logs with 
the server output etc? A general observation is that most of the issues 
around end-user/GUI applications are clearly documented in the draft, 
the headless application environment case less so. It makes me wonder if 
this JEP should be split so that it initially focuses on the former.

I think it would be useful if the JEP explained what an "application" 
is. Is it a JAR file (with a Main-Class) that is deployed on the class 
path? Can it be a module? What about modules and libraries that the 
application uses. Users of javapackager might know these things but 
readers of the JEP may not.

The JEP mentions that JavaFX will be removed in JDK 11. I assume this 
should be clarified so that it's clear it will no longer be shipped in 
Oracle's JDK. It's a none issue for those using OpenJDK builds as the 
the JavaFX modules were never bundled/imported by default.

There are several references to "server JRE" that probably should be 
clarified as this notion does not exist in OpenJDK. It may be that the 
JEP just needs to clearer as to the modules that it links into the 
run-time image.

There are several references to "application launcher" and "native 
launcher". At some point we need to work out some issues with jlink as 
it it will need to generate native launchers too. The JEP could list it 
as an issue as the development of this JEP will at least touch on some 
of this.

The draft doesn't have a section on testing. If someone is building 
OpenJDK then will they will require additional tools in the build 
environment and can the tests be run without manual interaction? Also 
how about a developer using the tool, will the generated native packages 
be easy to un-install so they can easily test in a local environment?

-Alan