Re: Compiling with JDK 11 or JDK 17
I'm OK with our tooling requiring whatever makes our lives simplest as long we can guarantee that the target byte codes and *API calls* will work on Java 8 for 2.x. Gary On 2023/03/08 19:29:29 Volkan Yazıcı wrote: > 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 > 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 > > >
Re: Compiling with JDK 11 or JDK 17
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 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 >
Compiling with JDK 11 or JDK 17
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
