Sealed interface quick fix in IntelliJ

Tagir Valeev amaembo at gmail.com
Fri Oct 9 06:28:44 UTC 2020


Hello!

Thank you for the pointer. Now I think that it's better to rename the
action to 'Seal hierarchy', so it will try to seal the selected class
with all the subclasses:
if subclass has no subsubclasses, then make it final
if subclass has subsubclasses in the same package/module, make it
sealed and perform the same check for these subsubclasses
if subclass has subsubclasses in different package/module, then make
it non-sealed

What do you think?

With best regards,
Tagir Valeev.

On Fri, Oct 9, 2020 at 4:42 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I suspct what they're doing is saying "well, A was extensible before, so
> let's not change that."  But I too would prefer that they default to
> `final` unless the user requests otherwise.  non-sealed should be rare.
>
> On 10/8/2020 5:31 PM, Remi Forax wrote:
> > I've just discovered that if there is already an existing interface with a class,
> >    interface I { }
> >    class A implements I { }
> >
> > you can ask IntelliJ to seal the interface using Alt+Enter (context actions) on the interface then choose "Seal",
> > but what IntelliJ does goes in the wrong direction IMO, it also adds "non-sealed" to the class A.
> >
> >    sealed interface I permits A { }
> >    non-sealed class A implements I { }
> >
> > Adding "non-sealed" seems wrong for me, usually what a user want is to close the hierarchy and not close only the interface, otherwise we would not have introduce the "non-sealed" keyword.
> > Adding the keyword "sealed" on the interface makes the class A to not compile anymore, i get that, but i think it's important to let the user choose if he wants to declare the class A final or non-sealed.
> >
> > regards,
> > Rémi
>


More information about the amber-dev mailing list