Experience with sealed classes & the "same package" rule

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 10 Juin 2021 00:39:20
> Objet: Re: Experience with sealed classes & the "same package" rule

> On Jun 9, 2021, at 3:20 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Sealed hierarchies are restricted to a package in the unamed module in order to
>> ease the migration when you add a module-info because a sealed hierarchy
>> restricted to a package is obviously restricted to a module.

> Adding module-info puts new restrictions
> on the relations between packages. That’s
> what modules are for. Subtraction of
> privilege is a legitimate use of modules.

No, it's more complex than that, adding a module-info just add boundaries. Then depending on the directive, it adds restrictions or it adds privileges. 
By example, adding a service is adding a privilege access to particular class of a package. 

> Adding new privileges is not a legitimate
> use of modules, IMO. If moving to modules
> is both additive and subtractive, you get
> two incompatible access control regimes
> (and even two languages), neither of which
> is a subset of the other.

It's both additive and substractive but on different planes (different directives). 

And even that is not fully true, by default requires is subtractive, if you don't require the content of a module, the packages of that module are not available but because you have incubator modules which content are not available through the unamed modules but available when you require the incubator module. 

>> If you relax that rule, you add another hindrance to the adoption of modules.

> That’s backwards. The rule, in its current
> form, is a an incentive to use modules
> (to get more flexible behavior). But it’s
> an unnatural incentive: It’s not what
> language rules are good for.

Again, it's about boundaries, if the boundaries do not exist, you can not define the behavior of it. 
In this particular case, adding a module define the boundaries of the packages that are compiled altogether, so it's safe to have cross package sealed types. 

Sealed types is a handshake feature, like nestmates, allowing packages from different jars to the part of the same closed hierarchy because there is no module defined is a recipe for disaster. 

> — John

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210610/9ab6ab97/attachment-0001.htm>