On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
> Can I please get a review of this change which proposes to implement the > enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes > - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any > sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` > and `RegularEnumSet` are the two permitted sub classes. Both of these > sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for > these 2 sub-classes was an option too. But I decided to start with the more > restrictive option since we don't have any other sub-classes and if and when > we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part > of this change, manual tests have been run to make sure that changing this > class to `sealed` and marking the sub-classes as `final` don't break any > serialization/deserialization semantics, across Java version and/or user > application versions. > > `tier1` testing across various platforms is currently in progress. Do we need a CSR as a public class is changed from non-sealed to sealed? (Although the constructor has been package-private and hence it will not affect any non-dk code as noted by Jaikiran via private conversation. Only reflection will be able to see the difference of non-sealed to sealed change). ------------- PR: https://git.openjdk.java.net/jdk/pull/7741
