On Jun 21, 2021, at 6:10 AM, Maurizio Cimadamore <maurizio.cimadam...@oracle.com<mailto:maurizio.cimadam...@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
