Support Adoptium "bootcycle-images" building to enhance reproducible builds and secure dev

[andrew-m-leonard]

Investigate the option of building openjdk using the "bootcycle-images" target, see: https://openjdk.org/groups/build/doc/building.html

This builds the JDK twice, the first time with the user chosen BootJDK, and then the final time using the JDK it just built.
So in essence the resulting jdk-nn is built using the same jdk-nn as the BootJDK.

This could have some advantages for reproducible builds and secure-dev:

1. This aids reproducible builds for users, as it neutralises differences in the initial BootJDK used. Making identical reproducible builds easier.
2. The procedure is more secure against vulnerabilities in the user selected BootJDK.

[stooke]

Please note that the results of the bootcycle build (which I recommend as the final product of the build) appear in a different directory inside the ./build directory.

[andrew-m-leonard]

A point to note, is this process is not enabled for cross-compiled builds.

[stooke]

I believe that macOS building on Apple Silicon and shipping on x86_64 should be supported.

[andrew-m-leonard]

A potential issue, is also the way Adoptium signs embedded Mac jmod dylib's using a dual pass "exploded-image", then sign, then "assemble-image", which is potentially not comaptible with bootcycle.
This process will be added to Windows as well soon.

[andrew-m-leonard]

To alleviate the issue of jrt-fs.jar being non-reporducible with different bootjdk, we need to investigate if upstream can re-build jrt-fs.jar after the "Build JDK" generation.

[andrew-m-leonard]

To alleviate the issue of jrt-fs.jar being non-reporducible with different bootjdk, we need to investigate if upstream can re-build jrt-fs.jar after the "Build JDK" generation.

So we can't quite(!), as the "Build JDK" or more accurately the "interim compiler" used with the standard build which then compiles the product modules, is just a compiler, as jdk-11+ versions do not build any jars (other than jrt-fs.jar).
So although the jrt-fs classes can be compiled, the "jar" used to construct the jrt-fs.jar would be from the bootjdk.

[andrew-m-leonard]

The other option to consider, to address the enhancement of a secure "bootcycle", would be to simply do 2 builds, and pass the output JDK from the first into the 2nd via --with-boot-jdk=<1st JDK>

[andrew-m-leonard]

This issue has been mitigated upstream in jdk21+ by changing the jrt-fs build to use the interim compiler: openjdk/jdk21u@e2b89c7