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

[Mike Hearn]

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.