On 22/06/2021 10:08, Remi Forax wrote:
------------------------------------------------------------------------
*De: *"John Rose" <john.r.r...@oracle.com>
*À: *"Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>
*Cc: *"daniel smith" <daniel.sm...@oracle.com>,
"amber-spec-experts" <amber-spec-experts@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
