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.
