<div dir="ltr">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<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 21, 2023 at 10:49 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">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"><u></u>
<div>
<p>On 2023-09-21 10:59, Andrew Leonard wrote:</p>
<blockquote type="cite">
<div dir="ltr">
<div>My only concern might be the fact the MANIFEST would say
"Created by: jdk-N-1", which is still accurate according to
the spec:</div>
<div> "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 <tt>jar</tt> tool."</div>
<div>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....</div>
<div>Thoughts?<br>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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...).</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 20, 2023 at
10:50 PM <<a href="mailto:erik.joelsson@oracle.com" target="_blank">erik.joelsson@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>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>On 9/20/23 08:12, Andrew Leonard wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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">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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>