Yes, now that JDK 17 is the minimum we can consider doing this. As you
mentioned, it would provide earlier notification of the error:
compile-time versus runtime.
One thing to add is that in addition to sealing Node, we would leave at
least Shape, Shape3D, Camera, and LightBase sealed, since they are also
not extensible and throw a similar runtime exception.
-- Kevin
On 2/1/2023 8:59 AM, Thiago Milczarek Sayão wrote:
Yes, sorry, I made the email title in plural, but I meant what Michael
said, Node would be sealed permitting only what is needed for JavaFx
internally.
-- Thiago
Em qua., 1 de fev. de 2023 às 13:48, Michael Strauß
<[email protected]> escreveu:
I don't think that's what Thiago is proposing. Only `Node` would
be sealed.
The following subclasses would be non-sealed: Parent, SubScene,
Camera, LightBase, Shape, Shape3D, Canvas, ImageView.
And then there are additional subclasses, which don't fit into this
idea since they are in other modules: SwingNode (in javafx.swing),
MediaView (in javafx.media), Printable (in javafx.web).
On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx
<[email protected]> wrote:
>
> I think this may be a bit unclear from this post, but you're
proposing I think to make `Node`, `Shape` and `Shape3D` sealed.
For those unaware, you're not allowed to extend these classes
(despite being public). For example Node says in its documentation:
>
> * An application should not extend the Node class directly.
Doing so may lead to
> * an UnsupportedOperationException being thrown.
>
> Currently this is enforced at runtime in NodeHelper.
>
> --John
>
> On 01/02/2023 15:47, Thiago Milczarek Sayão wrote:
>
> Hi,
>
> NodeHelper.java has this:
>
> throw new UnsupportedOperationException(
> "Applications should not extend the "
> + nodeType + " class directly.");
>
>
> I think it's replaceable with selead classes. Am I right?
>
> The benefit will be compile time error instead of runtime.
>
>
> -- Thiago.
>
