Refinements for sealed types

[Brian Goetz]

I do, because the other way to get a class into the same compilation unit, aux classes, have some limitations.  So we’re encouraging the pattern of nesting.  But … I am not sure we want to push it all the way.  Consider a type like:

    sealed interface Fruit {
        interface RedFruit extends Node { }
        interface BlueFruit extends Node { }
        class Strawberry implements RedFruit { }
        class Raspberry implements RedFruit { }
        class Blueberry implements BlueFruit { }
    }

Do we want to force Blueberry to be Fruit.BlueFruit.Blueberry (or at least, twist the user’s arm into it by offering less ceremony?)  I think that would be lame — and worse than lame if the intermediate interfaces (RedFruit, BlueFruit) were not public.  Then we’d be nesting the public types in the nonpublic ones, and they’d be inaccessible.  

> You often show the concrete classes as members of a sealed interface. Interface members are already implicitly public and static; is this a precedent to build on for a sealed interface? That is, have the nested concrete classes be implicitly final, and have the interface's implicit `permits` list care about only nested concrete classes. Top level concrete classes in the same compilation unit would be handed like concrete classes in other compilation units: nothing different than today.
> 
> Layering sealing on top of nesting has the attraction that it avoids putting multiple public concrete classes in a single compilation unit. It's right that the concrete leaves are public, but javac dislikes compilation units with multiple public types.
> 
> Alex