jmods-less jlinking prototype

[Dan Heidinga]

On Fri, Mar 17, 2023 at 7:34 AM Mike Hearn <mike at hydraulic.software> wrote:

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

Hi Mike,

There's certainly benefits to this approach.  I think there's a fair bit of
synergy between your approach and the larger set of use cases I wrote up in
my response to Alan (see other fork of this email thread).  A common
pattern across some of the use cases is the need to decouple the "inputs"
(modules, jmods, etc) from the JDK running jink.  Once that's possible - as
Severin shows in his prototype - it becomes simpler to talk about different
sources of modules including remote sources.

>From a Leyden perspective, I'm more interested in exploring how to extend
jlink to allow condensing previously condensed images as I see that
developing into a more common usage pattern in large enterprises with
platform teams providing preconfigured supported JDK's to their teams which
support further customization.  Kind of akin to a build pack approach.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230320/b3fa8232/attachment.htm>