PreviewFeature on packages and modules
Alex Buckley
alex.buckley at oracle.com
Thu Feb 4 21:47:05 UTC 2021
On 2/4/2021 9:53 AM, Alex Buckley wrote:
> 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.
We should probably switch "top-level classes" to "public classes,
whether top level or nested". The preview module might not export a
package, in which case it doesn't matter that we treat the package's
public classes as preview (since they're inaccessible); but if the
preview module does export a package, then we should recognize its
public nested classes as part of the API alongside its public top level
classes (consider j.l.i.MethodHandles.Lookup).
Alex
More information about the compiler-dev
mailing list