On Thu, 7 Apr 2022 18:36:55 GMT, Sergey Bylokhov <s...@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
