JDK 17 delivered JEP 409: Sealed Classes : https://openjdk.java.net/jeps/409
As well as being used for future classes this can be retrofitted to
suitable existing API classes where provably there can be no application
sub-classes since there are no public or protected constructors and
at least one package access constructor

A scan for these has identified various classes in the desktop module as candidates
Some of these turn out to have no subclasses and these should be marked final instead
of sealed.

Not all classes that can be sealed may be worth the effort or seem appropriate
They maybe classes that simply happen to have a limited set of subclasses
currently defined but have no natural set, and absence of public and protected constructors
already is sufficient.
Or they may have internal platform-specific sub-classes which require special treatment
That is, a sealed class must declare which classes it permits to sub-class, and those
classes must be accessible at compile time. A platform-specific subclass will not
be present except on that platform so the code will fail to compile on other platforms.
Solutions would either be to move the platform class to shared code - not always
appropriate, or to introduce a shared subclass which is un-sealed but otherwise
unchanged and then have the platform classes extend that.

These are possible of course, but it maybe a question of whether it is worth it.

For the java.awt.color package the candidate classes are below and are annotated either FINAL or SEALED to indicate the treatment they should receive.

SEALED java.awt.color.ICC_Profile
FINAL java.awt.color.ICC_ProfileGray
FINAL java.awt.color.ICC_ProfileRGB