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

[Alex Buckley]

On 3/10/2022 2:20 PM, Remi Forax 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.
> 
> I don't think you can do that because it means that the view at compile time and the view at runtime now disagree.
> 
> From the VM POW, a class is in preview mode or not, if a class contains a preview method, this class is marked as in preview mode,
> so even if javac allows the compilation, it will not work at runtime.

I know what you mean, but the Thread class itself is not a preview API 
and Thread.class is not poisoned. Ordinary code that refers to Thread 
(e.g., to extend it, or to call its traditional methods) will compile 
and run without preview warnings/errors.

Code that tries out Loom by referring to preview methods in Thread 
(e.g., Thread::ofVirtual) will require --enable-preview at compile time. 
The class files generated for such code will get poisoned, and require 
--enable-preview at run time.

Alex