RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes

Gavin Bierman gavin.bierman at oracle.com
Tue May 19 12:48:37 UTC 2020



> On 19 May 2020, at 13:44, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi Vicente,
> 
> javac changes look overall OK to me.
> 
> A few comments:
> -the handling of non-sealed in JavacParser is fairly good, even though I wonder if handling it in the tokenizer would not be better. If I read the specification correctly, "non-sealed" is specified as a keyword, so the tokenizer would seem like a proper place to recognize it (when preview is enabled, etc.). So, I think this:
> class NonSealed {
>    {
>        int non = 0;
>        int sealed = 0;
>        int c = non-sealed;
>    }
> }
> 
> should not compile, but it does. In any case, not sure if there are tests for broken/strange non-sealed, like "non -sealed", "non/**/-sealed", "non\u002Dsealed".

That’s actually a bug in the spec (to be filed). I believe now the intent is to treat non-sealed as a contextual keyword, which is what the compiler does.

Gavin


More information about the core-libs-dev mailing list