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

[Alex Buckley]

On 3/10/2022 2:05 PM, Maurizio Cimadamore wrote:
> 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?

B is like a class X that uses a preview language feature somewhere in 
its declaration. The use of a preview language feature poisons X.class, 
but other classes can refer to X (and yet more classes can refer to 
them...) without being poisoned themselves. A large program that uses X 
deep down might be able to run for a long time even with preview 
features disabled; only when the program triggers loading of X will the 
VM complain.

B uses a preview API (overrides a preview method) but is not a preview 
API itself, so C can refer to B without getting poisoned. Of course, C's 
particular use of B (`extends`) means that loading C causes loading of B 
and then you'd better have --enable-preview -- but other uses of B are 
possible that would let C load and run without --enable-preview.

Alex