My only concern might be the fact the MANIFEST would say "Created by: jdk-N-1", which is still accurate according to the spec: "Created-By: Defines the version and the vendor of the java implementation on top of which this manifest file is generated. This attribute is generated by the jar tool." However, people would probably jump to the conclusion that the classes there in are jdk-N-1 compiled, when they are actually compiled by jdk-N.... Thoughts?
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. >>> >>>
