P3
In short generated permits clause in enums that have a constant with a body should be ignored by sigtest.
Long story:
According to the spec on sealed classes:
Assertion before spec change: "An enum declaration is implicitly final unless it contains at least one enum constant that has a class body (8.9.1)."
Afer spec change:
"An enum declaration is either implicitly final or implicitly sealed, as follows:
An enum declaration is implicitly final if it contains no enum constants that have a class body (8.9.1).
An enum declaration is implicitly sealed if it contains at least one enum constant that has a class body. The permitted subclasses (8.1.6) are the anonymous classes implicitly declared by the enum constants that have a class body."
Binary compatibility rules from JLS:
13.4.26. Evolution of Enums
"Adding or reordering constants in an enum will not break compatibility with pre-existing binaries.
If a pre-existing binary attempts to access an enum constant that no longer exists, the client will fail at run time with a NoSuchFieldError. Therefore such a change is not recommended for widely distributed enums.
In all other respects, the binary compatibility rules for enums are identical to those for classes."
New binary rules from sealed classes spec:
13.4.2.1 sealed Classes
"If a class that was not declared sealed is changed to be declared sealed, then an IncompatibleClassChangeError is thrown if a binary of a pre-existing subclass of this class is loaded that is not contained in its permits clause; such a change is not recommended for widely distributed classes.
Changing a class that is declared sealed to no longer be declared sealed does not break compatibility with pre-existing binaries."
13.4.2.2 non-sealed Classes
"Changing a class that is not declared non-sealed to be declared non-sealed does not break compatibility with pre-existing binaries.
Changing a class that is declared non-sealed to no longer be declared non-sealed does not break compatibility with pre-existing binaries."
------------
Lets see what happens.
1. Let's say enum had a constant without body and another implementation added a body.
JDK 14 behavior: enum was final and became non-final. Internal anonymous class represents constant with body.
JDK sealed behavior: enum was final and became sealed with permits for internal anonymous class representing constant with body.
No IncompatibleClassChangeError should be seen since the only pre-existing subclass is the anonymous one that is listed in permits.
2. enum had a constant with body and another implementation removed a body.
JDK 14 behavior: enum was non-final and became final.
JDK sealed behavior: enum was sealed with permits clause and became final.
Long story:
According to the spec on sealed classes:
Assertion before spec change: "An enum declaration is implicitly final unless it contains at least one enum constant that has a class body (8.9.1)."
Afer spec change:
"An enum declaration is either implicitly final or implicitly sealed, as follows:
An enum declaration is implicitly final if it contains no enum constants that have a class body (8.9.1).
An enum declaration is implicitly sealed if it contains at least one enum constant that has a class body. The permitted subclasses (8.1.6) are the anonymous classes implicitly declared by the enum constants that have a class body."
Binary compatibility rules from JLS:
13.4.26. Evolution of Enums
"Adding or reordering constants in an enum will not break compatibility with pre-existing binaries.
If a pre-existing binary attempts to access an enum constant that no longer exists, the client will fail at run time with a NoSuchFieldError. Therefore such a change is not recommended for widely distributed enums.
In all other respects, the binary compatibility rules for enums are identical to those for classes."
New binary rules from sealed classes spec:
13.4.2.1 sealed Classes
"If a class that was not declared sealed is changed to be declared sealed, then an IncompatibleClassChangeError is thrown if a binary of a pre-existing subclass of this class is loaded that is not contained in its permits clause; such a change is not recommended for widely distributed classes.
Changing a class that is declared sealed to no longer be declared sealed does not break compatibility with pre-existing binaries."
13.4.2.2 non-sealed Classes
"Changing a class that is not declared non-sealed to be declared non-sealed does not break compatibility with pre-existing binaries.
Changing a class that is declared non-sealed to no longer be declared non-sealed does not break compatibility with pre-existing binaries."
------------
Lets see what happens.
1. Let's say enum had a constant without body and another implementation added a body.
JDK 14 behavior: enum was final and became non-final. Internal anonymous class represents constant with body.
JDK sealed behavior: enum was final and became sealed with permits for internal anonymous class representing constant with body.
No IncompatibleClassChangeError should be seen since the only pre-existing subclass is the anonymous one that is listed in permits.
2. enum had a constant with body and another implementation removed a body.
JDK 14 behavior: enum was non-final and became final.
JDK sealed behavior: enum was sealed with permits clause and became final.