Searching…
The features and schedule of this release were proposed and tracked via the JEP Process, as amended by the JEP 2.0 proposal. The release was produced using the JDK Release Process (JEP 3).
They were proposed again, with refinements, by JEP 397 and delivered in JDK 16 as a preview feature. This JEP proposes to finalize Sealed Classes in JDK 17, with no changes from JDK 16.
We intend this JEP to coincide with JEP 405, which defines two new kinds of patterns that support nesting. The implementation will likely make use of dynamic constants (JEP 309).
The maintainers will clear this label when development of the next release (17.0.5 in the example) is started. jdk17u-todo Changes Oracle backported to older releases that are not backported to open jdk17u. We mostly ...
This JEP is the successor to JEP 396, which transitioned the JDK from a default of relaxed strong encapsulation to a default of strong encapsulation, while allowing users to return to the relaxed posture if they wished.
Please see JEP 385 for the full background, rationale, risks, and alternatives. The Java EE Platform contained a technology called the JavaBeans Activation Framework (JAF).
For N >= 9, the documented APIs consist of (i) the APIs exported from those modules in the JDK image which are part of the documentation of JDK N; and (ii) the API exported from the jdk.unsupported module (documented ...
The Graal compiler was made available as an experimental JIT compiler in JDK 10 via JEP 317. We have seen little use of these experimental features since they were introduced, and the effort required to maintain and e...
Therefore, there is negligible behavior compatibility risk from the changes in this JEP. Even on platforms where non-strict execution could occur, there was no idiom to force non-strict evaluation.
The macOS/AArch64 port and the Windows/AArch64 port (JEP 388) will likely share some code. Some parts of this JEP will depend upon the integration of JEP 388, while other parts can be developed in parallel.
