Well, one thing that changed in JUL is that it requires the java.logging module. Otherwise, the Java 8+ stuff is for the System.Logger API.
> On Aug 9, 2024, at 07:20, Piotr Karwasz <pkarw...@apache.org> wrote: > > Hi Ralph, > > On 2024/04/09 21:46:28 Ralph Goers wrote: >>> On Apr 9, 2024, at 12:34 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> >>> wrote: >>> 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`. >> 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. > > If I interpret this correctly: > > * we can remove from the `main` branch the `log4j-iostreams` artifact since > it only extends `log4j-api`, which uses Java 8. > * we can remove from the `main` branch the SLF4J artifacts, since it uses > Java 8 bytecode. `log4j-slf4j-impl`, `log4j-slf4j2-impl` and `log4j-to-slf4j`. > * `log4j-jpl` should stay since it requires Java 11 or more. > * What about `log4j-jul` and `log4j-to-jul`? They have a Java 17 version, > although I sincerely doubt anything changed there since Java 8. > > Piotr
