<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I'm curious to know why these classes are not allowed to be
subclassed directly, as that may be important in order to decide
whether these classes should really be sealed.<br>
</p>
<p>--John<br>
</p>
On 01/02/2023 20:37, Kevin Rushforth wrote:<br>
<blockquote type="cite"
cite="mid:20593394-0e70-dd72-c55e-b493716456b4@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I read the spec for sealed classes more carefully, and it turns
out we can't make Node sealed. At least not without API changes to
SwingNode and MediaView (and implementation changes to Printable
in the javafx.web module). All of the classes listed in the
"permits" clause must be in the same module, and SwingNode
(javafx.swing) and MediaView (javafx.media) extend Node directly
they would need to be "permitted" subtypes, but there is no way to
specify that. We would also need to do something about the tests
that extend Node and run in the unnamed module. So this doesn't
seem feasible.<br>
<br>
We could still seal Shape, Shape3D, LightBase, and Material, since
all permitted implementation are in the javafx.graphics module. It
may or may not be worth doing that.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/1/2023 9:45 AM, Nir Lisker
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+0ynh-5=Vf5k6EDzQROjHz5-K5BqAaCF-Bq7bLVh+0V57Q93A@mail.gmail.com">
<div dir="ltr">I'll add that internal classes, mostly NG___
peers, can also benefit from sealing. NGLightBase is an
example.
<div><br>
</div>
<div>Material is another public class that can be sealed.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 1, 2023 at 7:37
PM Kevin Rushforth <<a
href="mailto:kevin.rushforth@oracle.com"
moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> 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>On 2/1/2023 9:06 AM, Philip Race wrote:<br>
</div>
<blockquote type="cite"> 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>On 2/1/23 8:59 AM, Thiago Milczarek Sayão wrote:<br>
</div>
<blockquote type="cite">
<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"
target="_blank" 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>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
</body>
</html>