I’ve just spent my weekend trying to do this. It took me quite a while to figure out that we are wrapping javac with something called errorprone and that the current configuration of it doesn’t work with Java 11. I managed to modify its configuration and got the compiles to work but StackLocatorUtilTest fails when using Java11. No great surprise since the test can’t find the Java 9 implementation since multi-release is only supported in jars, not in the directory structure and the Java 8 implementation won’t work with Java 11.
Then I proceeded to copy the Java 9 files into log4j-api into src/main/java9. First I tried having multiple executions of the compiler plugin. While I could get it to try to compile it gets compile errors trying to compile module-info.java in all the references to packages that are part of the Java 8 compile. I then modified the build to use the antrun plugin as described at https://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/ <https://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/> and got the exact same errors. It seems that just as in our multi-module setup all the packages have to be present in the compile to be able to compile module-info.java. While this could be solved by copying all the dummy stuff from the java9 module to the src/main/java9 directory and then having the copy step exclude them this just seemed like as much of a hack as what we are currently doing. In addition, I realized that having two classes with the same package and class name is going to cause problems for IDEs. Also, testing Java 8 and Java 11 classes together in one module could possibly be done but would be a bit tricky. But since I couldn’t get it to compile I couldn’t even try. At that point I gave up with this adventure. The only sane way to do this is to only support Java 9+ (or Java 11+ since it is unlikely anyone will ever use Java 9 or 10 in production) in master. Ralph > On Nov 7, 2020, at 4:47 PM, Matt Sicker <boa...@gmail.com> wrote: > > I think there's a potential compromise in > https://issues.apache.org/jira/browse/LOG4J2-2922 > > Depending on how that works out, it may still be possible to support > Java 8, or it would potentially allow for 2.x and 3.x to maintain some > build compatibility to make it easier to backport anything. > > On Sat, 7 Nov 2020 at 17:38, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> One of the goals for 3.0 is to have it fully support the Java Platform >> Module System. Currently, we are required to have a java 8 project and a >> java 9 project and merge them. If we say that 3.0 will only support Java 11+ >> then we can get rid of these extra projects and add module-info.java to all >> of the projects. >> >> Of course, we can continue development of the 2.x versions for as long as we >> want to continue to support Java 8 (which I believe will be quite a while >> yet. https://www.jrebel.com/blog/2020-java-technology-report, >> https://snyk.io/wp-content/uploads/jvm_2020.pdf, and >> https://www.jetbrains.com/lp/devecosystem-2020/java/ all indicate that well >> over 50% of applications are using Java 8). >> >> Thoughts? >> >> Ralph >
