> None of these classes can be extended by user code, and any attempt to do so > will fail at runtime with an exception. For this reason, we can seal the > class hierarchy and remove the run-time checks to turn this into a > compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other > modules, preventing those derived classes from being permitted subclasses. A > non-exported `AbstractNode` and `AbstractShape` class is provided just for > these scenarios. Note that introducing a new superclass is a source- and > binary-compatible change (see [JLS ch. > 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the > specification in any meaningful way. There can be no valid JavaFX program > that is affected by this change.
Michael Strauß has updated the pull request incrementally with one additional commit since the last revision: remove documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1556/files - new: https://git.openjdk.org/jfx/pull/1556/files/c24aed5c..38b7a22e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=00-01 Stats: 23 lines in 5 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1556.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556 PR: https://git.openjdk.org/jfx/pull/1556
