Improving compiler messages for preview API

[Tagir Valeev]

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

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.

With best regards,
Tagir Valeev.

On Sat, Aug 3, 2019 at 7:36 AM Stuart Marks <stuart.marks at oracle.com> wrote:

>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190803/0125de68/attachment.html>