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