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