[jdk21u-dev] RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

[Volker Simonis]

On Wed, 23 Jul 2025 17:49:21 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Almost clean backport of JDK-8335619, except for a conflict in the copyright header (year). Adds useful information for users of `java.lang.instrument`.
>
> Hi @fandreuz, 
> this change might need a CSR if backported, or even a change of the standard.  Can you please check 
> with Joe Darcy that it is fine to backport this as-is?  
> I'll remove the label in the meantime.

HI @GoeLin,

I don't think this backport requires a CSR. I've evaluated the need for a CSR in the [initial PR](https://github.com/openjdk/jdk/pull/20011) and came to the conclusion (together with the reviewers) that it [is not needed because](https://github.com/openjdk/jdk/pull/20011#issuecomment-2208685235):

 > Notice that according to the [CSR FAQ](https://wiki.openjdk.org/display/csr/CSR+FAQs), I don't think that this change requires a CSR because it is not changing the specification but merely describes the actual behavior in some more detail:
> 
> >    Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed?
> >    A: A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review.

Also, the `@apiNote` is a non standard (i.e. JDK-scope and not SE-scope tag, see [JDK-8068562: javadoc tags to distinguish API, implementation, specification, and notes](https://bugs.openjdk.org/browse/JDK-8068562)), so again, because this is not specification relevant, I think no CSR is needed for the backport.

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/2012#issuecomment-3112493215