Is it better for JDK to distribute jmod files independently of JDK itself?

[Glavo]

Merging jmod on different platforms sounds like an attractive idea.
However, I don't care about it during this time, because I need some
architectures whose ports are not in OpenJDK main-line as jlink targets, so
I can't get JDK from only one provider.

Mike Hearn <mike at plan99.net> 于2022年2月9日周三 05:01写道：

> Hi Glavo,
>
> My company is currently working on something you can think of
> as jpackage++. Amongst other tasks it invokes jlink to create a JDK
> distribution for each targeted operating system. It has JPMS support so
> I'll post about it on this list when a release is available for public
> download.
>
> We had the same thoughts as you. JMODs look quite wasteful but as Alan
> points out, they are the raw inputs to an optimization pipeline. In theory
> jlink can do anything. Jigsaw is a 'finished' project, so there is unlikely
> to be any changes to OpenJDK packaging anytime soon. The best way is to
> lead by example. Unfortunately that would mean creating a new JDK
> distribution and some bandwidth costs, so you might be better off asking
> Microsoft, Amazon or some other JDK distribution to try something new here.
> Although we can ask for OpenJDK to lead by example by making suggestions,
> realistically the relevant people are engaged on other higher impact
> projects right now. It's just the way it is.
>
> You've suggested several bits of JMOD related low hanging fruit. It's
> probably best to just write a specification and then implement them!
> You/I/we could:
>
> 1. Take some JDKs and make the JMODs available as separate downloads.
> Write a simple spec that defines a URL convention, so given a JDK URL the
> platform specific versions and JMODs can be easily located via string
> interpolation. Then try and get Amazon/Microsoft/etc to implement the spec.
>
> 2. Define a convention so the target platform is incorporated into JMOD
> file names. Then a single set of JMODs can be used to create linked JVMs
> for all supported platforms at once.
>
> 3. More ambitiously, extend the JMOD format with platform specific
> directories and write a classloader library that extracts/loads native
> libraries on the fly. Then the JAR format can be replaced with JMODs, such
> that a single file represents a truly cross-platform artifact even for
> cases like JavaFX or java.base, where native libs/different classes are
> required. For bonus points, fork the clever jimage format to a separate
> spec so the benefits of jimage's perfect hashing and string dedupe can be
> obtained from Maven Central downloads, without requiring OpenJDK to commit
> to the format.
>
> None of these projects are difficult. We've considered doing some of them
> already, but there were always higher priorities. The limits of JMOD are in
> the end just a disk space/bandwidth waste, so we focus for now on higher
> impact developer productivity issues.
>
>
>