> On 19 May 2020, at 13:44, Jan Lahoda <jan.lah...@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
