<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hello Andrew,</p>
<p>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.</p>
<p>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.</p>
<p>/Erik<br>
</p>
<div class="moz-cite-prefix">On 9/20/23 08:12, Andrew Leonard wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFFhbGNjAiJTkfGCKjpYmJMA55FM553sM+HOOig6SZMAOs=ozg@mail.gmail.com">
<div dir="ltr">
<div>Hi Magnus,</div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>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....</div>
<div><br>
</div>
<div>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...</div>
<div><br>
</div>
<div>Cheers</div>
<div>Andrew</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 20, 2023 at
2:44 PM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">magnus.ihse.bursie@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>On 2023-09-20 09:38, Andrew Leonard wrote:</p>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks Alan,</div>
<div><br>
</div>
<div>So different gcc, glibc, Xcode,.. agree, they need
to be the same for identical bits.</div>
<div>However, at the moment using the same toolchains,
if you do a standard product build,</div>
<div>and then a bootcycle build, of the same source,
jrt-fs.jar will differ.</div>
<div>I'll do some investigation of the make files to see
if a "Build JDK" rebuild of jrt-fs.jar is</div>
<div>feasible.</div>
</div>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>(Also, questions about the build process is preferably
handled on the build-dev list)</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Cheers</div>
<div>Andrew</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 19, 2023
at 5:42 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Alan.Bateman@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 18/09/2023
14:51, Andrew Leonard wrote:<br>
> Thanks for the clarification Alan.<br>
><br>
> To ensure the reproducibility of the whole JDK
image regardless of the <br>
> specific bootjdk used, would it make sense once
the "Build JDK" has <br>
> been built, we re-build jrt-fs.jar again using
the "Build JDK" ? Thus <br>
> jrt-fs.jar will be consistent with the rest of
the image in terms of <br>
> what it is compiled with.<br>
><br>
<br>
The boot JDK will be JDK N-1, or the newly built JDK
in the case of boot <br>
cycle builds. It seems a bit of a stretch to have
builds using different <br>
tool chains to produce identical bits but maybe you
mean something else.<br>
<br>
In any case, for jrt-fs.jar the important thing is
that they are <br>
compiled to --release 8 (that might rev at some
points) so that <br>
IDEs/tools can open a target run-time image as a file
system and access <br>
the classes/resources.<br>
<br>
-Alan.<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>