Sounds like the conclusion is: > On Apr 24, 2020, at 1:16 PM, Dan Smith <daniel.sm...@oracle.com> wrote: > > I presented this as an outline of our choices, but to put a stake in the > ground, here are my preferences. > >> On Apr 23, 2020, at 12:27 PM, Dan Smith <daniel.sm...@oracle.com> wrote: >> >> 1) Is it legal to have a permitted subclass/subinterface that does not >> actually extend the permitting class or interface? > > At compile time, no. Let's prohibit that. > > At run time, delay any validation until a particular subclass is loaded.
Agreement on both of these. (Requires a new rule in the language spec.) >> 2) What are the constraints on module membership? > > At compile time, do nothing. Per (1), it's already impossible to successfully > declare a sealed parent/child across a module boundary. > > At run time, require the same run-time module. In the corner case of a > parent/child split across class loaders (in unnamed modules), we say "sorry, > don't do that." (I do think this will come up. Extension is an important way > to communicate across class loader boundaries. But I think programs doing so > need to accept that sealed types are not for them.) Agreement on both of these. (Language spec can mention the module implication, but doesn't need to make it a rule.) >> 3) What are the constraints on package membership? >> >> The use case here is a class/interface extending a sealed class/interface, >> both in the same unnamed module. > > At compile time, do nothing. Per (1), it's impossible to separately compile > the parent and child, no matter what packages they are declared in. > > At run time, there's nothing to enforce. I don't care how you've deployed > your class files, as long as they successfully compiled and have the same > module/loader. The compile-time package restriction should stay, as a nudge away from unwanted circularities. There's a choice to make at run time, with some disagreement. I think it makes sense to leave it out for now. (Only way to get into this situation is to generate bytecode with something other than javac. You can't get there with separate compilation.)
