I completely support both initiatives: 1. Moving the JDK to 17 (why stay at 11?) 2. Moving `log4j-jmx-gui` to a separate repository
We have pulled a similar stunt in `log4j-tools`: it uses JDK 11, though targets 8. We can easily move `log4j-jmx-gui` to a separate repository by copying the project infra (README, CI, release process, etc.) from `log4j-tools`. On Fri, Mar 3, 2023 at 10:45 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi, > > Compiling 2.x using JDK 8 requires a lot of tricks: > > * Surefire scans classes using the main Maven JDK, so we must be sure > `module-info.class` and other Java 9+ classes are not on the test > classpath. This basically means we need to delete them before testing > and creating them afterwards. > * We need toolchains even if we disable tests, > * Some Maven or compiler plugins (like Error Prone) either require > Java 11 or are hard to configure on Java 8. > > That is why I would propose to bump the JDK requirement in the POM > file to JDK 11+ (for `log4j-jpl`) and add `--release 8` everywhere it > makes sense. > > For reproducibility purposes the CI and apache-release profiles would > still need to fix a JDK (JDK 17?) for compilation and a JRE (JRE 8) > for testing. But a casual user will be able to run the build process > without toolchains. > > I have a working prototype on this branch: > > https://github.com/ppkarwasz/logging-log4j2/tree/java17 > > The only problem I wasn't able to solve is to compile `log4j-jmx-gui` > with JDK 11+: it requires `jconsole.jar` in the classpath, all JDK's > after 8 have a module for that. I think we could move it to a separate > repo. > > Remark that `log4j-api`, which uses `sun.reflect.Reflection`, compiles > perfectly with JDK 17 and `--release 8`. > > Piotr >
