Experience with sealed classes & the "same package" rule
Brian Goetz
brian.goetz at oracle.com
Mon Jun 21 13:18:35 UTC 2021
> 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."
More information about the amber-spec-experts
mailing list