Experience with sealed classes & the "same package" rule

[Brian Goetz]

The rule is the tail; the dog is that "sealing is tight coupling, so 
sealed hierarchies should be co-maintained."  We don't have formal 
maintenance boundaries, but packages (for non-modular code) and modules 
(for modular code) are the closest approximation.  Bristling at the rule 
is really bristling at the fact that we don't have a formalized notion 
of maintenance domain.

On 6/21/2021 8:31 PM, John Rose wrote:
> On Jun 21, 2021, at 6:10 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>> Could we live w/o that rule? Sure we probably could, but let's not 
>> assume that dropping that rule is "free": the Panama API/impl would 
>> have to be refactored pretty heavily to take advantage of sealing w/o 
>> that rule (while, with current rules we could just drop "sealed" 
>> where it belongs, and everything just works).
>
> I’d like us to say little more about this forced
> refactoring, because I’m not fully understanding
> your point yet.
>
> Suppose the rule were dropped, and sealing
> were allowed across packages in all cases,
> not just for modularized packages.
>
> If you left your code the same, you’d have
> implementation classes in package P2,
> as public names, and API classes in package
> P1, again as public names.  The module that
> contains P1 (perhaps with the same name
> as P1), exports P1, while it contains but does
> not export P2.
>
> (I agree this is a nice very use of packages
> that has been enabled by modules!)
>
> Code that loads such a non-modularized
> “JAR-style” bundle would then have access
> to public names in P2, since there is no
> module boundary to prevent that.
>
> The effect of stripping modular structure
> from P1 and P2 is to break open the module
> so that P2’s contents are more accessible
> to some random P3.
>
> If this breaks the encapsulation pattern of
> P1 and P2, then it would need to be fixed,
> if the de-modularized P1 is to be made
> viable as an alternative product.
>
> (Immediate question:  Isn’t this just a case
> of “if it hurts then don’t do it”?  If that’s
> true, then it doesn’t count as a cost of
> simplifying the rule, to be agnostic about
> modularity when validating sealing.
> It’s just a use case that gets no benefit
> from simplifying the rule,)
>
> I guess fixing this, by re-securing P2 somehow,
> would require the refactoring you are
> talking about here, perhaps merging P2
> into P1 so P2’s public classes can be
> downgraded to package-private.
>
> There would be other fixes possible also,
> such as having P2’s types validate their
> use through capability passing Lookups.
> That gums up the code but avoids large
> scale refactors.  And the sealing would
> remain intact.  The cross-calls into
> P2 API points that are private would
> have to use capabilities.
> Have I got the gist of it?
>
> If so, I don’t think the relative usefulness
> of modularity (with or without sealing) is
> anything other than a neutral observation.
> Modularity is useful, and if you back out
> of it, you have to give up some utility.
> Perhaps you have to add other means of
> access checking (capabilities) to make up
> the deficit.
>
> That argument does not make sealing
> less useful or more dangerous in a
> non-modular setting, in a manner
> unique to sealing.  So, I still fail to see
> why the proposed simplification has
> any downside at all.
>
> — John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210623/8fa2896a/attachment.htm>