RFR: 8273328: Compiler implementation for Pattern Matching for switch (Second Preview)

[Jan Lahoda]

On Thu, 4 Nov 2021 14:01:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
>
>> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
> 
> Ok - maybe you are considering the case where `I` is used in a compilation unit which did not defined it. And which cannot (for some reason) see B.  Seems cornery, but what I'm mostly worried about is that it's not (I think) uniform with the rest of the javac code dealing with sealed classes. For instance, look at the cast conversion rules in `Types::areDisjoint` - in that case there's no protection against missing types.
> 
> I think the compiler code should be consistent in how we reason about sealed permitted types?

Right, the case is where the sealed class/interface is used from some other project. It is somewhat cornery, but might happen even for us - consider an sealed API interface in the JDK, which has permitted classes that are in an implementation package. The `--release` data normally do not include non-API packages, so when looking at the API interface, we may encounter a class that does not exist.

I didn't realize there is the same issue with `areDisjoint`, but you are right it suffers from the problem and that it should be consistent. I'll take a look at that, possibly separately, if that's OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209