RFR: 8282823: javac should constrain more uses of preview APIs

[Maurizio Cimadamore]

On Thu, 10 Mar 2022 12:28:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a class or interface with a method marked as preview. Subclassing the class or implementing the interface by itself should not cause a preview error/warning (as that would be problematic for Loom), but overriding the method should produce a preview error/warning.
> 
> This patch adds the error/warning in case a preview method is overridden.

Question - what happens if you have:

class A {
   void m() { ... } // THIS IS PREVIEW
}

class B extends A {
    void m() { ... } // override, ok, classfile polluted
}

class C extends B {
    void m() { ... } // ?
}


My understanding is that C will also get a pollute classfile version - but not because of the override (because javac cannot see that the method being overriden is, in turn, the override of another preview method deep down); instead, I believe C get warning/polluted classfile because it's using B, which has a polluted classfile. But what if both B and  C are compiled together?

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

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