Hi Erik, Thank you for the feedback. Yes, I think I agree with you, changing the compilation to "interim" would resolve the reproducibility, and also would be beneficial from the "secure dev" perspective having the classes built with the "latest&greatest" compiler. I will create a bug & PR, and perform some testing.
Cheers Andrew On Wed, Sep 20, 2023 at 10:50 PM <erik.joels...@oracle.com> wrote: > Hello Andrew, > > The bootcycle-images target is AFAIK just a test. It's certainly not meant > to be the authoritative way of building the JDK. Using JDK N-1 as bootjdk > is the official way of producing a JDK of version JDK N. For convenience, > and because it should work, we also allow JDK N. Vendors should definitely > not be encouraged to use bootcycle builds to produce their JDK binaries. > > Switching the compiler to interim would help with the reproducibility > issue. I would support that change. I don't think we can reasonably do > something about the jar tool. > > /Erik > On 9/20/23 08:12, Andrew Leonard wrote: > > 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. >>> >>>
