[Bug] javac gives non-deterministic output (for sealed interface with records)

[-]

Hi Przemek,
Since you say this happens "intermittently", like how often does it happen
(like 50% of the time or way less frequent)? And does it happen with Java
21 as well? I have tried to create minimal cases to reproduce on Java 21,
but to no avail.
I think the class 222 you've attached in the emails should be the correct
one, while class 80 seems to be wrong, as the PermittedSubclasses should be
declared in class file in the order they are present in the source file.

A preliminary examination shows that other 2 attributes NestMembers and
InnerClasses are solely handled by ClassWriter while the implicit
PermittedSubclasses depends on TypeEnter's processing order. That might be
a clue if we can confirm that this happens on Java 21.

Chen

On Mon, Dec 18, 2023 at 2:51 AM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> Hey Folks,
>
> I'm not 100% sure it's the best idea to post it here but I have no access
> to the JDK JIRA (yet?) 🙈
>
> 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.
>
> *## Expected behavior*
>
> 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.
>
> *## Bug description*
>
> 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.
>
> I also attach the compiled bytecode coming from two different CI agents.
> If you compare the bytecode you will notice this:
> [image: image.png]
> 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.
>
> "javap -c -l -private" shows that the output is exactly the same (but it
> isn't).
>
> The only difference between the CI nodes is the Linux kernel version
> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-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.
> Here's the screen from Develocity showing the diff in the infrastructure.
> [image: image.png]
>
> 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.
>
> 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.
>
> Cheers,
> Przemek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231224/ceee21f3/image-0003.png>