Hi Magnus, So yes, jrt-fs.jar can be different between a normal build and a bootcycle build, which is where I sort of came in here... For example, building say jdk-21 using a jdk-20 bootjdk, you will find that there is an extra inner class in the standard build of jrt-fs.jar, due to the fact that the jdk-21 compiler optimized the inner class generation for enum's somewhere, such that jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a jdk-20 compiled jrt-fs.jar!
I did experiment, and you can simply switch jrt-fs.jar to be COMPILER="interim", however when it comes to the jar's construction via "jar", it obviously uses the bootjdk "jar" command since the "interim-compiler" is just a compiler.... In summary, I suspect this is just eluding to what the real purpose of "bootcycle-images" is, which I think is essentially a "test", and I suspect most vendors will either just do a standard "product-images" build, or perform their own bootcycle by doing two builds... Cheers Andrew On Wed, Sep 20, 2023 at 2:44 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2023-09-20 09:38, Andrew Leonard wrote: > > Thanks Alan, > > So different gcc, glibc, Xcode,.. agree, they need to be the same for > identical bits. > However, at the moment using the same toolchains, if you do a standard > product build, > and then a bootcycle build, of the same source, jrt-fs.jar will differ. > I'll do some investigation of the make files to see if a "Build JDK" > rebuild of jrt-fs.jar is > feasible. > > I would not in general assume that a normal build and a bootcycle build > produce identical results. A bootcycle build will build the product using a > newer version of the JDK (viz. the one you just build from the sources), > and as such, changes to javac can result in different class file outputs, > etc. That being said, for large time periods of the JDK source code, a > normal build and a bootcycle build can certainly result in the same output, > since no changes have been made in the product that affects how .class > files are generated. But that is not guaranteed, nor is a difference > between normal and bootcycle build a sign of trouble or a defect. > > If jrt-fs.jar is consistently different between a bootcycle build and a > normal build, that sounds a bit odd, though. Especially since it should be > built with `--release 8` (or something like that) to ensure it is usable on > older Java; and that output ought not to really change as the JDK develops. > > (Also, questions about the build process is preferably handled on the > build-dev list) > > /Magnus > > > > Cheers > Andrew > > > On Tue, Sep 19, 2023 at 5:42 PM Alan Bateman <alan.bate...@oracle.com> > wrote: > >> On 18/09/2023 14:51, Andrew Leonard wrote: >> > Thanks for the clarification Alan. >> > >> > To ensure the reproducibility of the whole JDK image regardless of the >> > specific bootjdk used, would it make sense once the "Build JDK" has >> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus >> > jrt-fs.jar will be consistent with the rest of the image in terms of >> > what it is compiled with. >> > >> >> The boot JDK will be JDK N-1, or the newly built JDK in the case of boot >> cycle builds. It seems a bit of a stretch to have builds using different >> tool chains to produce identical bits but maybe you mean something else. >> >> In any case, for jrt-fs.jar the important thing is that they are >> compiled to --release 8 (that might rev at some points) so that >> IDEs/tools can open a target run-time image as a file system and access >> the classes/resources. >> >> -Alan. >> >>
