<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>On 2023-09-20 09:38, Andrew Leonard wrote:</p>
    <blockquote type="cite" cite="mid:CAFFhbGOJ1qGmq6OrjTvH6tdRSKS+JBsHg1t8zzRsmxnjC-OgFQ@mail.gmail.com">
      
      <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" cite="mid:CAFFhbGOJ1qGmq6OrjTvH6tdRSKS+JBsHg1t8zzRsmxnjC-OgFQ@mail.gmail.com">
      <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" 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>
  </body>
</html>