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