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