Experience with sealed classes & the "same package" rule

[John Rose]

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/20210622/5db878df/attachment-0001.htm>