Experience with sealed classes & the "same package" rule

[Brian Goetz]

> When working with modules, it is a fairly common practice to structure 
> applications are libraries in multiple set of packages - a package 
> containing the publicly exported types by a given module, and another 
> package containing the "implementation types". I find this way of 
> splitting much more natural than dumping everything into the same 
> package and rely on access modifiers to only expose what I want, and, 
> we use this pattern extensively in the Panama API.

And, there's a reason you use this pattern; the design of the modules 
feature encourages this.  Earlier explorations of modularity had 
module-visibility for classes and members; if that were still the case, 
you could have a public interface and a module-visible implementation of 
that class in the same package.  But this fine-grained accessibility 
model was dropped, and modules became groups of packages, some of which 
are exported and some of which are not.  Unless everything is in one 
package, it's pretty hard to organize your source base into anything 
other than "public interfaces in one package, module-public encapsulated 
implementations in another."