Experience with sealed classes & the "same package" rule

[John Rose]

On Jun 9, 2021, at 3:20 PM, Remi Forax <forax at univ-mlv.fr<mailto: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.

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.

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.

The main “hindrance” to adding modules
is teasing apart cross-package accesses.
Having sealed classes be a Very Special
Case of cross-package accesses does not
help; it only makes the story murkier.

So, yes, removing the rule will remove
a twisted incentive to go to modules.
Is that “another hindrance” to modules?
Maybe, but it’s the right thing here.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210609/362736a6/attachment.htm>