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

[Phil Race]

On Thu, 7 Apr 2022 18:36:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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?
>
> Thank you for your clarification.

You have to include it in the list, else it would not be a permitted sub-class, and then you couldn't use the new syntax at all.

the javadoc doesn't mention it - it still just says
public sealed class GroupLayout.ParallelGroup
extends [GroupLayout.Group]

My recollection is that if there are also public classes the generated javadocs cites the public one and appends the text "and others" ,,  to mean the private ones .. I don't know why it does that but it still doesn't expose the internal class

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

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