JDK-8282131 : java.time.ZoneId should be a sealed abstract class
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-02-18
  • Updated: 2022-03-19
  • Resolved: 2022-02-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 b12Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Description
The impl spec of java.time.ZoneId states that ZoneId has two implementations:
    "One implementation models region-based IDs, the other is {@code ZoneOffset} modelling offset-based IDs."

The ZoneId constructor has this check to ensure no other subclass can extend it:
    ZoneId() {
        if (getClass() != ZoneOffset.class && getClass() != ZoneRegion.class) {
            throw new AssertionError("Invalid subclass");
        }
    }

ZoneId can be made a sealed abstract class that permits ZoneOffset and ZoneRegion to extend.  The test in the constructor would no longer be needed.
Comments
Changeset: 0ae3d1d5 Author: Naoto Sato <naoto@openjdk.org> Date: 2022-02-28 13:22:15 +0000 URL: https://git.openjdk.java.net/jdk/commit/0ae3d1d59c44e966e13345b9197fcf067e63900e
28-02-2022

A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7625 Date: 2022-02-25 19:02:55 +0000
25-02-2022

I agree with this change - a sealed class is perfect for this (I previously suggested on the mailing list)
25-02-2022