RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D

[Nir Lisker]

On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

> 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.

I thought about doing this some years ago for `Shape3D`, `Material` and `LightBase` when I was adding light types. `Shape3D` states:

> An application should not extend the Shape3D class directly. Doing so may lead to an UnsupportedOperationException being thrown.

However, I didn't see enough value in this. There is some small benefit for `LightBase` because it allows an exhaustive switch on its subtypes in `NGShape3D` (IIRC). Also, for `Material` and `LightBase`, even before compile time - at code writing time - the user will find it impossible to subtype these. `Shape3D` can be made to allow inheritance as its subtypes don't require native-level handling. I assume that this is why it has a comment about subtyping, and there is more benefit in sealing it.

The downside is minor too: custom shaders will allow user implementations, but that's not coming any time soon.

Since removing `sealed`/`final` from a class can be done in the future without much hassle, I'm not against sealing the above classes (and removing the comments about not extending them). It just doesn't overcome the initial inertia for me. I will review the changes for these classes if this goes forward.

As for `Node` and `Shape`, I didn't look at subclassing them and never thought about it, so I have no opinion there.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334357687