[External] : Re: PreviewFeature on packages and modules

[Alex Buckley]

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