<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>