Should we build jrt-fs.jar again with the "Build JDK" ?

[erik.joelsson at oracle.com]

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.bursie at 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.Bateman at 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.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230920/864f40da/attachment.htm>