RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause

Vicente Romero vicente.romero at oracle.com
Thu Jun 4 23:01:46 UTC 2020


thanks for the review, I will update the code with your proposed change 
before pushing

Vicente

On 6/4/20 5:28 PM, Maurizio Cimadamore wrote:
>
> Hit "send" too fast - small tweak suggested - instead of:
>
> sym.permitted = !permittedSubtypeSymbols.isEmpty() ?
> + permittedSubtypeSymbols.toList() :
> + sym.permitted;
> Just go for:
>
> if (!permittedSubtypeSymbols.isEmpty()) { sym.permitted = 
> permittedSubtypeSymbols.toList(); }
>
> Maurizio
>
> On 04/06/2020 22:24, Maurizio Cimadamore wrote:
>>
>> Changes look good.
>>
>> Maurizio
>>
>>
>> On 03/06/2020 21:22, Vicente Romero wrote:
>>> Please review the fix for [1] at [2], this patch if fixing the 
>>> following issue, javac doesn't accept code like:
>>>
>>> final class B extends A {}
>>> sealed class A {}  // no permits clause
>>>
>>> the reason is that when analyzing the permits clause of the sealed 
>>> class, the permitted list was overwritten without checking if it 
>>> wasn't empty. This is fixed now. Also as the presence of annotation 
>>> processors can provoke several iterations on the same code, now it 
>>> is necessary to clean out the `permitted` list if annotations 
>>> processors are present. This avoid that an iteration can find 
>>> symbols stored in this list by a previous iteration. Given this new 
>>> dependency on annotation processors of the sealed classes code, test 
>>> SealedCompilationTests has been modified to be executed twice: with 
>>> and without a simple annotations processor to stress this 
>>> dependency. There is a change that is not strictly related to the 
>>> main theme of the patch which is this one liner:
>>>
>>> diff -r 0a32396f7a69 -r 3a73b52df56b 
>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
>>> --- 
>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java 
>>> Wed Jun 03 12:09:04 2020 -0400
>>> +++ 
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java 
>>> Wed Jun 03 15:25:41 2020 -0400
>>> @@ -717,7 +717,6 @@
>>>              ListBuffer<Symbol> permittedSubtypeSymbols = new 
>>> ListBuffer<>();
>>>              List<JCExpression> permittedTrees = tree.permitting;
>>>              for (JCExpression permitted : permittedTrees) {
>>> -                permitted = clearTypeParams(permitted);
>>>                  Type pt = attr.attribBase(permitted, baseEnv, 
>>> false, false, false);
>>> permittedSubtypeSymbols.append(pt.tsym);
>>>              }
>>>
>>> permitted subclasses can't have type parameters thus this line is a 
>>> no-op, but given that the bug was related to the permits clause I 
>>> found this issue and addressed it as part of the patch,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8246486
>>> [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200604/bc23aba3/attachment-0001.htm>


More information about the compiler-dev mailing list