vlsi opened a new issue, #3984: URL: https://github.com/apache/logging-log4j2/issues/3984
spotbugs-annotations brings two nullability annotations which might accidentally cause wrong import being selected by the developer. 1) Here's a sample in log4j code: https://github.com/apache/logging-log4j2/blob/4b7065b8b3818cabb88cf1d553da33897b733413/log4j-core-test/src/test/java/org/apache/logging/log4j/core/appender/SocketAppenderReconnectTest.java#L24 2) Gradle treats Maven's `provided` as if they were `compileOnly` dependencies. In other words, Gradle projects that depend on `log4j2` **do** get `provided` dependencies on their `compileClasspath`. In fact, it makes sense: if the project required a dependency to be present during compilation, then the one who depend on such a module should also have those dependency on the compile classpath. The justification is that annotations (e.g. `@Nullable`) do impact the API of a module, and, say Kotlin compiler might properly infer if the parameter type is nullable or not based on the annotation. If the annotation is not present on the compile classpath, then the compilation might fail. Note: this is exactly the reason why Guava keeps `@Nullable` annotation on their `compile` scope. Apache JMeter uses log4j2 for logging, and it turns out that log4j2 brings `spotbugs-annotations` and its `@Nullable` annotations which makes it inconvenient to maintain code. I know I can configure IDE to avoid unwanted imports, however, it is IDE-specifc. What do you think of removing spotbugs-annotations dependency altogether? PS I asked SpotBugs developers to deprecate their nullable annotations, so the clients get warnings at least, however, they insist that they can deprecate their nullability annotations only when they get full support for JSpecify: https://github.com/spotbugs/spotbugs/issues/3811 Frankly, I do not believe SpotBugs will get full JSpecify support in the nearest future (why spending time on it provided there's NullAway and friends?) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
