You are forgetting one small thing. Plugins in 3.x use ServiceLoader while 2.x uses the Log4j2Plugins.dat file. While 3.x supports the old format it will be much better for users to not have to use the transformer when building uber jars as most tooling supports ServiceLoader out of the box.
Not only is 3.x compiled with Java 17 that is also the target version. If the component they are targeting also has a minimum version of Java 17 then it definitely makes sense IMO to have then in 3.x. However, SLF4J still targets Java 8 and I haven’t seen any indication that will change anytime soon. I do agree with your assumption about Spring Boot though. Ralph > On Apr 9, 2024, at 12:34 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > Since Log4j Core 3.x moved to `log4j-api` 2.24.0, many artifacts that > only depend on `log4j-api` became redundant in the 3.x branch: > > * `log4j-iostreams`, > * `log4j-jpl`, > * `log4j-jul`, > * `log4j-slf4j-impl`, > * `log4j-slf4j2-impl`, > * `log4j-to-jul`, > * `log4j-to-slf4j`. > > Right now the `3.x` version of these artifacts is basically the same > as the `2.x` version, except it is compiled with Java 17 instead of > Java 8. They could have some regression though. > > What should we do with those artifacts? They are already JPMS modules, > they don't need dependency injection, they barely use 2 Log4j system > properties (in `log4j-jul`, but JUL by definition has a single global > logger context, so these props must be global). > > I would propose to remove them from the `main` branch and just > reference the `2.24.0` version in the `3.0.0` version of `log4j-bom`. > > It will be easier to convince Spring Boot to bump the version of > `log4j-bom` to `3.0.0` if the bump will not change **anything** in > `spring-boot-starter-logging` (the default Logback-based stack) and > will only change the version of `log4j-core` in > `spring-boot-starter-log4j2`. > > Piotr
