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.
