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

[David Alayachew]

I'm not Vicente, but I'm 99% sure this is the link that would have been
sent.

https://openjdk.org/groups/build/doc/building.html

On Tue, Dec 19, 2023 at 12:02 PM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> Probably - I don’t have the environment and I also never built the JDK
> from sources it I have a technical skills to eventually do it 😉
>
> Can you pls point me to some docs on how to build the JDK from scratch?
>
> Cheers,
> Przemek
>
> W dniu wt., 19.12.2023 o 17:56 Vicente Romero <vicente.romero at oracle.com>
> napisał(a):
>
>> Hi Przemek,
>>
>> can you patch JDK sources, rebuild them and try if a given patch fixes
>> your issue or do you need a customized JDK?
>>
>> Thanks,
>> Vicente
>>
>>
>> On 12/19/23 03:48, Przemek Bielicki wrote:
>>
>> Oh damn! I think IDEA's decompiler helped a little with the explanation
>> of the meaning of the order.
>> As you can see from the attached screenshot the order of permits differ:
>>
>> permits GradleExecGraphNodeExecutionInfo.Task,
>> GradleExecGraphNodeExecutionInfo.Transform {
>> vs.
>> permits GradleExecGraphNodeExecutionInfo.Transform,
>> GradleExecGraphNodeExecutionInfo.Task {
>>
>> I guess this structure (collection of permits?) is handled by the
>> compiler using some sort of Set instead of a List thus we get a
>> non-deterministic order.
>> My fellow Gradle colleagues told me that they discovered such
>> non-determinisms in the past and the reasons were very similar.
>>
>> I hope it's helpful and can unblock you from digging deeper? 🤞🏻
>>
>> What's interesting is that javap isn't showing this difference. 🤔
>>
>> Cheers,
>> Przemek
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/90a3ec2f/attachment.htm>