Thanks Magnus, yeah it is still doing as it says on the "tin", so I think i'm just being paranoid! I'll put a PR together for review, cheers
On Thu, Sep 21, 2023 at 10:49 AM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2023-09-21 10:59, Andrew Leonard wrote: > > 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? > > If the definition of the `Created by` field says it is set by the jar tool > that generated the jar file, then this is as it should be, and we should > not try to change it. > > It is not in our powers to stop people from jumping to (incorrect) > conclusions, based on their misunderstanding of the specifications (even > though I often wished that it were...). > > /Magnus > > > > > 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. >>>> >>>>