I suspect we have some places in the code where classes and interfaces are public purely to allow us to extend/implement them in other packages in Boot. We may be able to declare some of them as sealed instead.
One thing that I'm not yet sure about is how this works with package tangles. Given that a sealed class in one package needs to declare that it permits extension by another class, if that class is in another package there'll be a cycle between the two packages. Perhaps such cycles just need to be ignored if you want to use sealed?
I've labelled this as a task for now. It might be closed or become an epic or an enhancement depending on what we decide.
Comment From: bclozel
It seems sealed classes have restrictions (though I didn't verify this behavior):
The classes specified by permits must be located near the superclass: either in the same module (if the superclass is in a named module) or in the same package (if the superclass is in the unnamed module).
Comment From: philwebb
I think we can close this one and adopt seals classes as and when we find the need. The one area I have found them useful is when we have an API that has a number of private implementations that get returned from a factory method. It's quite useful to declare that we don't expect subclasses to exist outside of those that we define.