[External] : Re: PreviewFeature on packages and modules
Alex Buckley
alex.buckley at oracle.com
Thu Feb 4 21:55:42 UTC 2021
That text would be corrected to clarify that adding a package
java.io.fast as a preview API in java.base (a perfectly good concept)
means the API designer has to flag classes in the package as preview
APIs (due to how @PreviewFeature is interpreted); and that _all_ classes
in the package (top level or nested; public or private) are
"participating". A private nested helper class should obviously be able
to refer to the in-preview public entrypoints of the API without
warning/error.
Alex
On 2/4/2021 12:55 PM, Nikita Eshkeev wrote:
> Will JEP lose this part about packages:
>
> > For example, if a package java.io.fast is introduced as a preview
> API, then all of the code in the package would be "participating" and
> would not generate errors/warnings when referring to the package's own
> types.
>
> ?
>
>
> 04.02.2021, 20:56, "Alex Buckley" <alex.buckley at oracle.com>:
>
> On 2/4/2021 8:44 AM, Jan Lahoda wrote:
>
> On 03. 02. 21 23:58, Alex Buckley wrote:
>
> In sum, there's a strong case for saying that everything
> in a preview
> module has preview status. (Where marking anything in the
> module with
> @PreviewFeature is legal but redundant.) This would be
> convenient for
> preview API designers, who could write @PreviewFeature
> once and have
> it trickle down.
>
> I suspect this is either very painful to implement in
> javac/javadoc,
> or very easy. Jan, please tell us which! :-)
>
>
> Propagating the preview flag from module to (top-level,
> presumably)
> classes seems to be fairly easy when compiling against
> classfiles.
> Propagating the flag from packages to classes would be more
> difficult,
> as the preview flag is commonly not read for packages - if we
> were to
> change that, we would need start reading all
> package-info.class files,
> with possible implications on performance.
>
>
> Thanks Jan (and Jon). Propagating the preview flag from module to
> top-level classes is all that's required. I'm happy to cut packages out
> of the discussion completely, both for the reason you give and because
> package-level annotations were a mistake. (Sharp-eyed readers will
> notice that JLS 9.6.4.6 no longer mentions "package" as a program
> element that can be deprecated.) If an API designer wishes to preview a
> new package, then every top-level class in the package will need to be
> flagged @PreviewFeature. JEP 12 can document all this after
> implementation.
>
> Alex
>
>
>
>
More information about the compiler-dev
mailing list