RFR: 8283706: Add final or sealed modifier to appropriate javax.swing API classes

[Joe Darcy]

On Wed, 6 Apr 2022 20:14:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, that is fine; javadoc will filter out displaying non-public classes in a permits clause.
>
> Just to double-check, it is fine to have it in the output of the getPermittedSubclasses for the public class as well?

I'm not certain what question you are asking. If the question is, is it fine for core reflection to return non-public information about the class, in general sure. For example, in jshell evaluating
StringBuilder.class.getSuperclass()
will yield
 class java.lang.AbstractStringBuilder
which is the non-public superclass of StringBuffer and StringBuilder.

If the question is, do the compatibility expectations of the platform include such visible non-public implementation artifacts? The answer is no; it is fine for those details to evolve and users shouldn't rely on them.

Is there another aspect of the change that was a concern?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8082