ppkarwasz commented on issue #3196: URL: https://github.com/apache/logging-log4j2/issues/3196#issuecomment-2477095522
> Now that's really bad. How are library authors and application developers supposed to cope with this? Do I understand correctly that if I have a dependency on lib A that is on log4j-api 2.23 and a lib B that is on 2.24, there's nothing I can do? In practice the problem is not as bad as it seems: - Log4j API 2.24.x **is** backward compatible with Log4j API 2.23.x, so you can use library A, B and `log4j-api` 2.24.x. Since we use semantic versioning (and we use [BND Baseline to check API compatibility](https://github.com/apache/logging-log4j2/blob/2.x/BUILDING.adoc#fixing-api-compatibility-check-failures)) if you have an application with 42 libraries that use Log4j API, you just need to pick the most recent version. Unfortunately this is **not** what Maven's conflict resolution does, that's why we encourage people to use `log4j-bom` for dependency management. It is the first step in [our installation guide](https://logging.apache.org/log4j/2.x/manual/installation.html#bom). - Even if library A **declares** a dependency on Log4j API `2.24.x`, it will **probably** work with Log4j API `2.13.x` or so. Log4j API and Log4j Core have a common versioning scheme. Most of the time the minor version bumps are due to Log4j Core. The last methods added to the public Log4j API were around `2.13.x`. The nature of the problem is different: once you **chose** the version of Log4j API, you **should** use Log4j Core of the same version. The `log4j-bom` artifact can ensure this. Note that this version alignment problem is common to all Java libraries split into API and implementation. If you write an application using Servlet API 2.0 and you deploy it on a Servlet API 2.4 server, at runtime Servlet API 2.0 will **not** be used, the server will provide Servlet API 2.4 to your application! > If it is as really you say, using log4j-api cannot be recommended to any library developer. SLF4J suffers from the same problems, without the additional help of semantic versioning. For example SLF4J `2.0.10` introduced a new [`Reporter`](https://www.slf4j.org/api/org/slf4j/helpers/Reporter.html) helper class. Every Logback version that uses this class is no longer compatible with SLF4J `2.0.9`! Note that some incompatibility problems with previous version of the API are unavoidable: the introduction of a new [`LogBuilder`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/LogBuilder.html) interface and [`Logger.atLevel()`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/Logger.html#atLevel(org.apache.logging.log4j.Level)) method in Log4j API 2.13.0 is **not** a breaking change, but causes Log4j Core 2.13.0 to throw `NoClassDefFound` errors if Log4j API 2.12.0 is present on the classpath. > Fixing this should have the highest priority in the log4j project and you should add test that make sure log4j-core works as expected with whatever version of log4j-api of the same major release is used. I agree that we should test our Log4j Core releases against **older** releases of Log4j API. As I explained above `log4j-core` version `2.0.1` can not possibly work with `log4j-api` version `2.24.1`, because it lacks the implementation of all the abstract methods that were introduced in the meantime. Such a combination will cause a lot of [`AbstractMethodError`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/AbstractMethodError.html)s. On the other hand we could try to develop Log4j API more carefully to allow Log4j Core 2.25.0 to be compatible with Log4j API 2.24.0. As I stated above, this is a **stronger requirement** that no breaking changes. I started [a thread on `dev@logging`](https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6), feel free to explain your point of view. -- 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]
