Improving compiler messages for preview API

[Stuart Marks]

On 8/2/19 5:07 PM, Alex Buckley wrote:
> 3. At run time -- If you compile without --enable-preview, and the source code 
> refers to an API element associated with a preview feature, then javac could 
> give a (non-suppressible) warning and _mark the class file as depending on 
> preview features_. It is important to handle this scenario firmly because the 
> API element might be gone in a later release. Annotating the type/method gives 
> grounds for javac to explain what's going on: "This method is marked @Preview; 
> your class file is now preview-feature dependent."

Yes, I have this concern as well. The API might be removed from a later release. 
Worse, its behavior might change incompatibly in a future release, possibly 
silently giving results that are incorrect from the application's point of view. 
Thus, I completely agree that firm treatment is required here.

Marking the compiled class as depending on preview features is good inasmuch as 
will prevent such errors. However, as we all know, people ignore warnings. They 
might end up with a build that produces an artifact that includes mostly normal 
class files but that includes a few preview class files. This artifact will work 
most of the time, until a preview-requiring class file is loaded, at which time 
the application will fail with an error that I think most people will find 
inexplicable.

Maybe a cleaner approach is to make use of a @Preview API an error in the 
absence of the --enable-preview option. This is putting a lot of weight on an 
annotation, perhaps too much; but I think it would be safer to explore this avenue.

s'marks