Some classes could be sealed
Thiago Milczarek Sayão
thiago.sayao at gmail.com
Wed Feb 1 16:59:08 UTC 2023
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ß <michaelstrau2 at gmail.com>
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 <john.hendrikx at gmail.com>
> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230201/73accc52/attachment.htm>
More information about the openjfx-dev
mailing list