<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
I agree that we should only seal existing classes that could not
have been extended by application classes. The ones I listed in my
previous email fit that bill, since an attempt to subclass them will
throw an exception when it is used in a scene graph. Each documents
that subclassing is disallowed.<br>
<br>
Btw, we've already started making use of pattern-matching instanceof
in the implementation anyway. It would be the first API change that
relies on a JDK 17 feature, but for JavaFX 21, I see no problem in
doing that.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/1/2023 9:06 AM, Philip Race wrote:<br>
</div>
<blockquote type="cite" cite="mid:54de6661-6e0a-7a98-2456-ef92cb6c2927@oracle.com">
In the JDK we've only sealed existing classes which provably
could not have been extended by application classes,<br>
so I'm not sure about this .. <br>
<br>
also I think that might be the first change that absolutely means
FX 21 can only be built with JDK 17 and later ..<br>
<br>
-phil<br>
<br>
<div class="moz-cite-prefix">On 2/1/23 8:59 AM, Thiago Milczarek
Sayão wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAAP_wu=6iBo67J=YZApaW0atD0X4DZc3KmFJHcb7TFonT00eYA@mail.gmail.com">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>-- Thiago<br>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em qua., 1 de fev. de 2023
às 13:48, Michael Strauß <<a href="mailto:michaelstrau2@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">michaelstrau2@gmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I don't think that's what
Thiago is proposing. Only `Node` would be sealed.<br>
The following subclasses would be non-sealed: Parent,
SubScene,<br>
Camera, LightBase, Shape, Shape3D, Canvas, ImageView.<br>
And then there are additional subclasses, which don't fit
into this<br>
idea since they are in other modules: SwingNode (in
javafx.swing),<br>
MediaView (in javafx.media), Printable (in javafx.web).<br>
<br>
<br>
<br>
On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx <<a href="mailto:john.hendrikx@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">john.hendrikx@gmail.com</a>>
wrote:<br>
><br>
> 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:<br>
><br>
> * An application should not extend the Node class
directly. Doing so may lead to<br>
> * an UnsupportedOperationException being thrown.<br>
><br>
> Currently this is enforced at runtime in NodeHelper.<br>
><br>
> --John<br>
><br>
> On 01/02/2023 15:47, Thiago Milczarek Sayão wrote:<br>
><br>
> Hi,<br>
><br>
> NodeHelper.java has this:<br>
><br>
> throw new UnsupportedOperationException(<br>
> "Applications should not extend the "<br>
> + nodeType + " class directly.");<br>
><br>
><br>
> I think it's replaceable with selead classes. Am I
right?<br>
><br>
> The benefit will be compile time error instead of
runtime.<br>
><br>
><br>
> -- Thiago.<br>
><br>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>