RFR: 8347755: Support static library in jmod [v4]

[Ethan McCue]

On Thu, 6 Mar 2025 16:47:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I thought the idea was that the jmod format was left intentionally undefined, to not think you could rely on anything else than the corresponding JDK tools to process it? That would mean backwards compatibility should not be a concern.
>
> (Just to be clear, this is about the JMOD format, not the jimage format. The jimage format is JDK internal and we are free to change it from release to release, even build to build, without compatibility concerns.)
> 
> You are right that the JMOD format is not documented but care is required when rev'ing the format because there are JDK tools that produce and consume this format. It should be possible for a project to produce a module in JMOD format with the `jmod` tool from JDK N, and put the package module on the module path when creating a run-time image with JDK N+1 `jlink`. So what Henry has looks right. It means the `jmod` tool will produce a 1.0 format when creating a package module that doesn't have static libs, and a JMOD in the new format when the module has static libs. This seems preferable to adding a `--release` option.

I guess its worth asking how would the format evolve in the future if more than `/static-lib` were added? Just as a strawman: say `/docs` and `/sources` were added in some sequence. Would this grow to say 


if (<nothing new>) {
   // 1.0
}
else if (<just static-lib>) {
   // 1.1
}
else {
   // 1.2
}


What if `/sources` (and corresponding generation of `src.zip`) were added first and `/docs` second?


if (<nothing new>) {
   // 1.0
}
else if (<just static-lib>) {
   // 1.1
}
else if (<just sources +/- static-lib>) {
   // 1.2
}
else {
   // 1.3
}


Or would, at that point, versioning move to be closer to what is done for classfiles.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/46#discussion_r1986138478