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

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Alex Buckley" <alex.buckley at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Jan Lahoda" <jlahoda at openjdk.java.net>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Friday, March 11, 2022 12:19:50 AM
> Subject: Re: RFR: 8282823: javac should constrain more uses of preview APIs

> 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.

Thanx,
i've taken a look to the generated bytecode, the new methods are tagged with Feature.VIRTUAL_THREADS but java.lang.Thread is not itself compiled with --enable-preview.

> 
> Alex

Rémi