> On Jun 22, 2021, at 4:05 AM, Maurizio Cimadamore
> <maurizio.cimadam...@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, 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.
> On Jun 23, 2021, at 7:04 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
> The rule is the tail; the dog is that "sealing is tight coupling, so sealed
> hierarchies should be co-maintained." We don't have formal maintenance
> boundaries, but packages (for non-modular code) and modules (for modular
> code) are the closest approximation. Bristling at the rule is really
> bristling at the fact that we don't have a formalized notion of maintenance
> domain.
I'm not really following the concern here. I understand discouraging "bad"
usage of the feature, which is why, all things being equal, sure, why not have
a rule where javac says "it looks like you're doing this wrong." But with those
sorts of error checks, we want to err on the side of permissiveness—I can't
tell for sure whether you're misusing the feature, so I'll let it go.
Another category of error check is when there's a mandatory invariant that must
be enforced, even if it involves false positives or annoying guardrails. It's
not clear to me why this error check would fall into that category.
Maybe a specific example could help?
Start with:
package foo;
class A {}
Compile to foo.jar.
package bar;
final class B extends foo.A {}
Compile with foo.jar on the classpath, get bar.jar.
Now refactor:
package foo;
sealed class A permits bar.B {}
Compile with bar.jar on the classpath. Either:
1) Error, "bar.B is in a different package"; or
2) Generate a revised foo.jar
Under (2), I've violated the "single maintenance domain" assumption, but...
when I run with foo.jar and bar.jar on the class path, everything works just
fine. I've manually introduced an explicit dependency from foo.jar on bar.jar
at compile time, which seems like a stupid thing to do, but sealed classes
don't seem any more problematic in this regard than mutually recursive method
signatures, etc.
As John noted, the JVM doesn't care about any of this and enforces its own
rules.
So: I'm not seeing a mandatory invariant that must be enforced, and that
justifies erring on the side of false positives.
> On Jun 22, 2021, at 3:08 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> 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.
Class circularities are prohibited at both compile time and run time. Nothing
new here.
Extra classes in a PermittedSubclasses attribute are harmless—the attribute
only has the effect of rejecting a certain class if it claims to extend another
but is not in the permitted list.
I'd love to have another achievable scenario of concern to think about (other
than the one I outlined above), but I'm having trouble envisioning it.
