jmods-less jlinking prototype

[Mike Hearn]

Hi Severin,

There's an alternative that can resolve some of the problems raised in
this thread, preserve the ability to cross-link (which is extremely
useful - many of our users rely on it), and also tidy up some rough
edges in the current packaging/distribution story. The idea is to stop
shipping JMODs with the JDK but enhance the release metadata file to
point to the URLs of those JMODs for each supported platform. JLink
can then use that metadata file to download any JMODs that are missing
before linking.

Advantages:

- Shrinks the base JDK download without the user needing to delete the
jmods directory.

- Ducks the issue of JLink transforming the files irreversibly.

- Preserves/enhances the ability to cross-link, without needing JMOD
format changes.

- The upgraded release metadata file can also be put online
separately, so tools can then be pointed to a single URL in order to
discover, download and generate a JDK of any platform from any vendor
(as long as they have access to a jlink already).

This would be similar to the approach Conveyor already uses, without
the proprietary parts. Currently we ship "stdlib" config files for
each JDK vendor and version that contains the URLs of the JDK
downloads, the tool then extracts that to get at the jmods inside,
then downloads a standard OpenJDK JDK for the host platform to get a
jlink, then uses jlink on each platform JDK to construct the JVM
that'll then be bundled with the app. The configs are in turn
generated by probing the foojay discovery API, but we've had stability
issues with it in the past. It'd be much simpler if users could just
be told to specify a magic URL for their vendor that covers all
versions of all platforms, especially if the JMODs were then "loose"
as it'd mean only the needed modules would be downloaded. Obviously,
it'd require vendors to be on board and change how they do uploads but
the current approach with flaky discovery APIs and zips-inside-zips is
kind of indirect and inefficient.

With respect to recursive linking/condensation, it might be a bit
early to think about that. As previously discussed people may want
optimized JDK images specifically for development purposes, and going
"sideways" from optimized-for-dev to optimized-for-release would be a
major complication. Making it efficient to start from a set of JMODs
and JARs seems like the way to go.