<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite">You can't extend these without tampering
with internals.</blockquote>
<br>
Pretty much, yes.<br>
<br>
Node is an abstract class that requires a concrete implementation to
be useful. The set of subclasses that can be used in describing and
rendering the scene graph is a finite and known set. The rendering
of the scene graph is an implementation detail; each node in the
scene graph has a corresponding peer (an NGNode subclass) that is
needed to implement various node types (shapes, images, etc).<br>
<br>
So Node, as well as its abstract subclasses, like Shape, Shape3D,
Camera, and LightBase, needs a known concrete subclass in order to
do anything. Similarly, Material (which is not a Node) is abstract
and has implementation that cannot be provided by an application
class.<br>
<br>
By contrast, Parent can be usefully subclassed. It is a concrete
class that is used as a container for other nodes, and has
implementation of layout, traversal, bounds computation, etc.<br>
<br>
--- Kevin<br>
<br>
<div class="moz-cite-prefix">On 2/1/2023 2:48 PM, Nir Lisker wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+0ynh-6dR+w7iUMVB98RWPFFUZRiLchm1-0ozR05d4zS7yq-Q@mail.gmail.com">
<div dir="ltr">For Material and LightBase it's because they are
just facades whose implementation is in native code. You can't
extend these without tampering with internals. I think that
Camera and Shape3D also requires modifying internal stuff,
though not at the native level.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 12:38
AM John Hendrikx <<a href="mailto:john.hendrikx@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">john.hendrikx@gmail.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>
<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"> 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>On 2/1/2023 9:45 AM, Nir Lisker wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank" 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>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>