<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 17, 2023 at 7:34 AM Mike Hearn <mike@hydraulic.software> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Severin,<br>
<br>
There's an alternative that can resolve some of the problems raised in<br>
this thread, preserve the ability to cross-link (which is extremely<br>
useful - many of our users rely on it), and also tidy up some rough<br>
edges in the current packaging/distribution story. The idea is to stop<br>
shipping JMODs with the JDK but enhance the release metadata file to<br>
point to the URLs of those JMODs for each supported platform. JLink<br>
can then use that metadata file to download any JMODs that are missing<br>
before linking.<br>
<br>
Advantages:<br>
<br>
- Shrinks the base JDK download without the user needing to delete the<br>
jmods directory.<br>
<br>
- Ducks the issue of JLink transforming the files irreversibly.<br>
<br>
- Preserves/enhances the ability to cross-link, without needing JMOD<br>
format changes.<br>
<br>
- The upgraded release metadata file can also be put online<br>
separately, so tools can then be pointed to a single URL in order to<br>
discover, download and generate a JDK of any platform from any vendor<br>
(as long as they have access to a jlink already).<br>
<br>
This would be similar to the approach Conveyor already uses, without<br>
the proprietary parts. Currently we ship "stdlib" config files for<br>
each JDK vendor and version that contains the URLs of the JDK<br>
downloads, the tool then extracts that to get at the jmods inside,<br>
then downloads a standard OpenJDK JDK for the host platform to get a<br>
jlink, then uses jlink on each platform JDK to construct the JVM<br>
that'll then be bundled with the app. The configs are in turn<br>
generated by probing the foojay discovery API, but we've had stability<br>
issues with it in the past. It'd be much simpler if users could just<br>
be told to specify a magic URL for their vendor that covers all<br>
versions of all platforms, especially if the JMODs were then "loose"<br>
as it'd mean only the needed modules would be downloaded. Obviously,<br>
it'd require vendors to be on board and change how they do uploads but<br>
the current approach with flaky discovery APIs and zips-inside-zips is<br>
kind of indirect and inefficient.<br>
<br>
With respect to recursive linking/condensation, it might be a bit<br>
early to think about that. As previously discussed people may want<br>
optimized JDK images specifically for development purposes, and going<br>
"sideways" from optimized-for-dev to optimized-for-release would be a<br>
major complication. Making it efficient to start from a set of JMODs<br>
and JARs seems like the way to go.<br></blockquote><div><br></div><div>Hi Mike,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>--Dan</div></div></div>