<div dir="ltr">> 

Maybe a cleaner approach is to make use of a @Preview API an error in the <br>> absence of the --enable-preview option. This is putting a lot of weight on an <br>> annotation, perhaps too much; but I think it would be safer to explore this avenue.<br><br><div>Completely agree: using a @Preview API should be an error in the absence of the --enable-preview option. Just like as using a preview syntax without --enable-preview is an error; not a "non-suppressible warning and special class file version". I think preview API should be handled in the same way as preview language features.</div><div><br></div><div>With best regards,</div><div>Tagir Valeev.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 3, 2019 at 7:36 AM Stuart Marks <<a href="mailto:stuart.marks@oracle.com">stuart.marks@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 8/2/19 5:07 PM, Alex Buckley wrote:<br>
> 3. At run time -- If you compile without --enable-preview, and the source code <br>
> refers to an API element associated with a preview feature, then javac could <br>
> give a (non-suppressible) warning and _mark the class file as depending on <br>
> preview features_. It is important to handle this scenario firmly because the <br>
> API element might be gone in a later release. Annotating the type/method gives <br>
> grounds for javac to explain what's going on: "This method is marked @Preview; <br>
> your class file is now preview-feature dependent."<br>
<br>
Yes, I have this concern as well. The API might be removed from a later release. <br>
Worse, its behavior might change incompatibly in a future release, possibly <br>
silently giving results that are incorrect from the application's point of view. <br>
Thus, I completely agree that firm treatment is required here.<br>
<br>
Marking the compiled class as depending on preview features is good inasmuch as <br>
will prevent such errors. However, as we all know, people ignore warnings. They <br>
might end up with a build that produces an artifact that includes mostly normal <br>
class files but that includes a few preview class files. This artifact will work <br>
most of the time, until a preview-requiring class file is loaded, at which time <br>
the application will fail with an error that I think most people will find <br>
inexplicable.<br>
<br>
Maybe a cleaner approach is to make use of a @Preview API an error in the <br>
absence of the --enable-preview option. This is putting a lot of weight on an <br>
annotation, perhaps too much; but I think it would be safer to explore this avenue.<br>
<br>
s'marks<br>
</blockquote></div>