<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    I think that having deterministic output is a very desirable
    property of a compiler but not a guarantee. If such non-determinism
    was provoking a compiler error this would be a higher priority
    error. Also as you determined yourself it is not possible to
    reproduce the issue with the test case you sent. We have made
    efforts in the past to remove sources of non-determinism in the
    compiler and I would say that the ones remaining are harder to
    remove. We could dive deeper with a reproductor but without that, it
    could be a futile effort,<br>
    <br>
    Vicente<br>
    <br>
    <div class="moz-cite-prefix">On 12/18/23 03:50, Przemek Bielicki
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com">
      
      <div dir="ltr">Hey Folks,
        <div><br>
        </div>
        <div>
          <div>I'm not 100% sure it's the best idea to post it here but
            I have no access to the JDK JIRA (yet?) ðŸ™ˆ</div>
          <div><br>
          </div>
        </div>
        <div>Last week I had a huge headache because of a bug I
          discovered in the Java compiler - Eclipse Temurin OpenJDK
          64-Bit Server VM 17.0.9+9 (mixed mode, sharing). I'm pretty
          certain it's a bug because my expectation is that the compiler
          MUST produce deterministic output of the compiled classes - at
          least when the JDK version is the same.<br>
        </div>
        <div><br>
        </div>
        <div><b>## Expected behavior</b></div>
        <div><br>
        </div>
        <div>Java compiler produces deterministic output i.e compiled
          byte code is exactly the same (SHA-wise) and is independent of
          the operating system type, version and other variables.</div>
        <div><br>
        </div>
        <div><b>## Bug description</b></div>
        <div><br>
        </div>
        <div>When compiling 1700+ classes in one of our modules on
          different CI agents (with exact same JDK version) I noticed
          intermittent SHA differences (of the compiled classes) that
          originated from a single class (the
          attached GradleExecGraphNodeExecutionInfo.java file.) It's a
          sealed interface and it uses records - I have an impression
          that using these two in conjunction plays a role here.</div>
        <div><br>
        </div>
        <div>I also attach the compiled bytecode coming from two
          different CI agents.</div>
        <div>If you compare the bytecode you will notice this:</div>
        <div><img src="cid:part1.ecBjfVD9.tWObdhA0@oracle.com" alt="image.png" class="" width="542" height="91"><br>
        </div>
        <div>The only difference (if the image is not displayed
          correctly) is that two same bytes (at the 0x440 position)
          switch the order depending on where the class is compiled. I
          didn't check the meaning of those bytes - I hope you can help
          here.</div>
        <div><br>
        </div>
        <div>"javap -c -l -private" shows that the output is exactly the
          same (but it isn't).</div>
        <div><br>
        </div>
        <div>The only difference between the CI nodes is the Linux
          kernel version (Linux 5.4.0-<b>166</b>-generic
          (amd64) vs Linux 5.4.0-<b>167</b>-generic (amd64). I was able
          to reproduce this behavior consistently when I compiled this
          module on different CI agents with the same difference in the
          Linux kernel.<br>
          Here's the screen from Develocity showing the diff in the
          infrastructure.</div>
        <div><img src="cid:part2.YpRQtovg.VAconaNA@oracle.com" alt="image.png" class="" width="542" height="183"><br>
        </div>
        <div><br>
        </div>
        <div>I tried to reproduce this problem with the minimal
          reproducer (by extracting the sealed interface outside of the
          big module) but I failed here. The produced byte code was the
          same.</div>
        <div><br>
        </div>
        <div>Please let me know if you need to check sources of the
          other classes referenced by this sealed interface. I'd need to
          get an approval before sharing them publicly.</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Przemek</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>