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