Experience with sealed classes & the "same package" rule

[Chris Hegarty]

> On 24 Jun 2021, at 01:25, Dan Smith <daniel.smith at oracle.com> wrote:
> 
>> On Jun 22, 2021, at 4:05 AM, Maurizio Cimadamore <Maurizio.Cimadamore at oracle.com> wrote:
>> 
>> I was working under the assumption that we would NOT just blindly allow different packages (e.g. in unnamed module) to access same sealed hierarchy in an uncontrolled fashion.
>> 
>> Without the natural boundary provided by modules, it seems like this would be problematic, and would essentially rely on the user "not trying too hard" (as Dan put it). So IMHO, the choice is between keeping the rules we have now, or backout the special rules around modules, and keeping all accesses to a sealed hierarchy package-confined. The middle ground seems murky and not strong enough, from a language perspective.
> 
> Yeah, to clarify: I was *not* suggesting that we should be more strict in module code. Cross-package type hierarchies are a useful feature! (One that we didn't invent when we created modules.)
> 
> My high-order complaint is that module source code can't be repackaged into an unnamed module,

To be clear, “re-packaged” here must include a recompilation step.

As the rules currently stand, it is possible to “re-deploy” a module on the class path - since the JVM rules are more lenient than of the JLS rules, here. So, re-deploying is currently possible with the rules as they stand - where “re-deployment" amounts to moving a modular jar from the module path to the class path.

> and this is something new in the language. My proposed resolution of this inconsistency is to be *less* strict, allowing cross-package extension in an unnamed module.

This would amount to (substantially) aligning the JLS rules with the current JVM rules, here. Which does not seem unreasonable. In fact, is attractive.

Aligning the JVM and JLS rules is attractive from a low-level or OpenJDK developers perspective, but will likely not be all that visible to the majority of developers writing Java code.  If we think that, in the absence of explicit modules, the approximation of maintenance domain to package is reasonable, then ok, this rule may carry its own weight. However, it is worth nothing that on the class path there is not a one-to-one relation between packages and jar files - split packages are tolerated. So maybe this JLS rule is not quite living up to its intent?

-Chris