PreviewFeature on packages and modules

[Jan Lahoda]

On 04. 02. 21 22:47, Alex Buckley wrote:

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


I'd point out it is not easy to refer to a nested class without first 
referring to the enclosing class (could happen e.g. when the code can 
refer to the nested class using simple name e.g. due to inheritance). 
And showing warnings on both the enclosing and nested class may be 
discouraging.


But there is a possibly bigger question: if we copy the flags from 
modules to nested classes, should we copy them from preview classes (in 
non-preview modules) to their nested classes? Or from preview classes to 
their members and constructors? (This is very unlike e.g. deprecation, 
which does not copy the flag to any enclosed element, AFAIK.)


Jan


>
> Alex