[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    Re: RFR: 8178701: Compile error with switch statement on protected enum defined in parent inner clas
From:       Vicente Romero <vromero () openjdk ! java ! net>
Date:       2022-04-26 22:05:30
Message-ID: _QPnXlLMYjxFttIhbu0rqs_5E6Q2toDWRCdsUGYJzQI=.fd6aa203-ef2c-479d-96e0-92eca619ed4e () github ! com
[Download RAW message or body]

On Fri, 25 Feb 2022 12:32:53 GMT, Jan Lahoda <jlahoda@openjdk.org> wrote:

> Consider the following code in two packages:
> 
> package foo;
> 
> import bar.D.E;
> 
> public class A {
> 
> public static class B {
> 
> protected enum C {
> X, Y, Z
> }
> }
> 
> public static void main(String... args) {
> new E().run(B.C.X);
> }
> }
> 
> 
> 
> package bar;
> 
> import foo.A.B;
> 
> public class D {
> 
> public static class E extends B {
> 
> public void run(C arg) {
> switch (arg) {
> default:
> System.out.println("OK");
> }
> }
> }
> }
> 
> 
> Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s \
> superclass. But, for the `switch`, javac creates a map (array) from runtime \
> ordinals of constants of `E` to compile-time positions. But, this mapping is in a \
> different class that does not extend `B`, so internal method lookups fail for it, \
> as the methods are not accessible per Java rules. 
> But, at runtime, the enum class is effectively public, so I think it is possible to \
> ignore the protected access rules and accept the method invocations while \
> generatting the mapping code, which is what this patch is trying to do.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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


[prev in list] [next in list] [prev in thread] [next in thread]