RFR: 8322477: order of subclasses in the permits clause can differ between compilations [v4]

[Chen Liang]

On Wed, 10 Jan 2024 17:27:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is a very interesting issue. Given code like:
>> 
>> sealed interface Sealed {
>>     record R1() implements Sealed {}
>>     record R2() implements Sealed {}
>> }
>> 
>> 
>> As we know javac will infer the `permits` clause of sealed interface `Sealed` logically the order should correspond to the order in which the permitted subclasses appear in the source code. Well it has been consistently observed by the reported of this bug, that some tools like Gradle while doing incremental compilation can make javac infer either `R1, R2` or `R2, R1` as permitted subclasses. The reason is not clear still under investigation on their side but the fact is that javac is generating inconsistent output for some classes with this shape. The proposed solution is to store the position of the permitted subclasses being discovered by javac so that the order of the permitted subclasses corresponds to the original order in the source file. Efforts to reduce the project where the issue was discovered to a small reproductor have been unsuccessful but the proposed patch have fixed the issue observed by the reporter.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1360:

> 1358:             permitted.clear();
> 1359:             for (Symbol csym : permittedSubs) {
> 1360:                 permitted.add(new PermittedClassWithPos(csym, 0));

If we have multiple `0` positions in the list, a future `addPermittedSubclass` call may not produce a deterministic list if it's called with pos `0`, as that's how `Arrays.binarySearch` behaves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17284#discussion_r1447712012