I should add to this that since I plan to add module-info files for every Log4j module this is going to mean creating java9 modules for every module we currently have. I really don’t want to do that.
Ralph > On Nov 8, 2020, at 10:26 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 >> <mailto:boa...@gmail.com>> wrote: >> >> I think there's a potential compromise in >> https://issues.apache.org/jira/browse/LOG4J2-2922 >> <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 >> >
