Following up on #232, Java 15's non-sealed keyword should also be highlighted:

It's part of JEP 360:

A sealed class imposes three constraints on its permitted subclasses (the classes specified by its permits clause):

The sealed class and its permitted subclasses must belong to the same module, and, if declared in an unnamed module, the same package.

Every permitted subclass must directly extend the sealed class.

Every permitted subclass must choose a modifier to describe how it continues the sealing initiated by its superclass:

A permitted subclass may be declared final to prevent its part of the class hierarchy from being extended further.
A permitted subclass may be declared sealed to allow its part of the hierarchy to be extended further than envisaged by its sealed superclass, but in a restricted fashion.
A permitted subclass may be declared non-sealed so that its part of the hierarchy reverts to being open for extension by unknown subclasses. (A sealed class cannot prevent its permitted subclasses from doing this.)
As an example of the third constraint, Circle may be final while Rectangle is sealed and Square is non-sealed:

package com.example.geometry;

public abstract sealed class Shape
permits Circle, Rectangle, Square {...}

public final class Circle extends Shape {...}

public sealed class Rectangle extends Shape
permits TransparentRectangle, FilledRectangle {...}
public final class TransparentRectangle extends Rectangle {...}
public final class FilledRectangle extends Rectangle {...}

public non-sealed class Square extends Shape {...}
One and only one of the modifiers final, sealed, and non-sealed must be used by each permitted subclass. It is not possible for a class to be both sealed (implying subclasses) and final (implying no subclasses), or both non-sealed (implying subclasses) and final (implying no subclasses), or both sealed (implying restricted subclasses) and non-sealed (implying unrestricted subclasses).

We support tree-sitter now, textmate grammar is sort of deprecated at this point. Most of the grammar comes from tree-sitter-java, so you would have to check if they handle the keyword there.

#234 was merged just 10 days ago, so I didn't expect it was deprecated already ;-)

Will look at tree-sitter-java, but if it doesn't support the latest Java 15 syntax, does it mean the content from #234 will be lost?

(for context) The deprecation seems fast in isolation, but the general policy across Atom for a long time now has been to focus only on the Tree-sitter version if it exists. And as of 10 days ago it now exists here too.

The TextMate grammars are still included and can be used by disabling Tree-sitter (either globally or Java specific). I guess in this case it's up to @sadikovi, but with other grammars with Tree-sitter support PRs for TextMate have been closed simply because Tree-sitter exists for them, and anyone still relying on the TextMate grammar was encouraged to maintain a fork of their own.

Support for the keywords may still need to be added here; Tree-sitter will parse a lot, but even if it parses those keywords some tokens might need to be discriminated further by Atom in order to apply different syntax highlighting (e.g., TS might parse public and protected as the same kind of token, so Atom would need to identify them like it does here). I haven't looked at any of the Java grammars though, so it's possible the TS Java parser doesn't parse them yet too.

Thanks @Aerijo! It simply took me one year to finally merge the tree-sitter PR 😄 . I will continue maintaining both versions as much as I can, while tree-sitter is catching up with the textmate grammar. I will be focusing on that mostly.

@fbricon Please, don't feel discouraged and do report suggestions and issues or even open PRs! All I was trying to say in my earlier post was that tree-sitter bugs and features will take priority over the textmate grammar now.

I will open the PR for the textmate to add non-sealed keyword later this week.