jjohannes commented on issue #3437: URL: https://github.com/apache/logging-log4j2/issues/3437#issuecomment-2648686124
My understanding of the argument why annotations with `CLASS` retention should be visible transitively (in certain cases) at compile time is: If, for instance, a public member of a Log4j class is annotated, it can be argued that that annotation is part of the public API at compile time – even though it's gone at runtime. If I now use tooling at compile time that visits the public API of all things used on the compile classpath, it may encounter this annotated method. Then it may be (at least theoreticaly) important that the class behind the annotation is available. That's what, to my understanding, the `-Xlint:classfile` check is validating: that all annotations on public members used during compilations are available. (Similar to how the compiler would fail if a superclass in the hierarchy is missing even though our own code does not interact with it directly.) As OSGi is only about runtime, it's no surprise that BND does not care about this as well. It took me some time and source code reading / debugging of BND's JPMS support, but I found the switch to add additional `require static` entries. As said above, I think these are harmless to add, as the compiler won't complain in general if they are missing. And at runtime, they are not of importance anyway. Only having both things – Gradle Metadata for `compileOnlyApi` dependencies and the additional `require static` entries – will solve the case I outlined in the description completely. Here is a PR that proposes to add both: https://github.com/apache/logging-log4j2/pull/3450 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
