rschmitt commented on PR #3852: URL: https://github.com/apache/logging-log4j2/pull/3852#issuecomment-3138487374
I'm actually releasing Log4j 2.25.1 right now. I've fixed all the known issues pretty much along the lines you've described, such as adding test dependencies on `jspecify` and disabling `-Werror`. This PR is the only one I'd like to see merged; all the other breakage is typical [Hyrum's Law](https://www.hyrumslaw.com/) stuff. > We had similar issue reports before, but we currently don’t have a clean long-term solution (short of bytecode manipulation to strip annotations). Suggestions are always welcome. I suppose the _long_-term solution is to wait for the Valhalla technology, in this case [null-restricted and nullable types](https://openjdk.org/jeps/8303099). Until then, nullability can only be modeled using third-party annotations, and most dependency managers don't have a concept of transitive compile-only dependencies (what Gradle calls `compileOnlyApi`). Even the Gradle solution seems weird to me, because a lot of these other annotation libraries certainly appear to be implementation details of Log4j's build process. Personally, I don't believe in linters. I think they provide very marginal benefits at the cost of significantly more fragile and complex builds. This whole thing with the `jspecify` annotations is just a story of everyone's linters fighting each other and breaking perfectly good builds over _nothing_. -- 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
