Experience with sealed classes & the "same package" rule

[Maurizio Cimadamore]

On 22/06/2021 10:08, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"John Rose" <john.r.rose at oracle.com>
>     *À: *"Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>     *Cc: *"daniel smith" <daniel.smith at oracle.com>,
>     "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>     *Envoyé: *Mardi 22 Juin 2021 02:31:13
>     *Objet: *Re: Experience with sealed classes & the "same package" rule
>
>
>
>     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.
>
>
> The proposed simplification allows different packages to share 
> different part of the sealed hierarchy without a module.
> So those packages can be in different jars, compiled at different times.
> This will produce "impossible" sealed hierarchies where by example two 
> types are both permitted subtypes of each other.
>
> We can save a lot of test and debugging time to a lot of people by 
> avoiding split sealed hierarchy.

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.

On the other hand, I recall the discussion around meaning of "public" 
when a class is in a module, and perhaps this is just "more of the same" 
- e.g. "sealed" provides a stronger guarantee _inside_ a named module.

Maurizio

>
>
>     — John
>
>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210622/708807cb/attachment.htm>