You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2020/11/07 23:38:17 UTC
Minimum Java version for Log4j 2 3.0?
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
Re: Minimum Java version for Log4j 2 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
It seems that I missed the test execution aspect in my original analysis.
That is indeed a blocker. I’d be open to requiring Java 11 if we can make
it easier to maintain and release 2.x concurrently. I’ve been trying to use
Java 11 (or whatever the latest release is at the time; 15 right now) by
default as my runtime environment, but I occasionally come across code that
hasn’t been updated yet (mostly parent pom things in my situation) to
properly support 9+. I think it’s important to support 11 so that it’ll
also be easier to support every other release after it.
On Sun, Nov 8, 2020 at 23:28 Ralph Goers <ra...@dslextreme.com> wrote:
> 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 <ra...@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 <boards@gmail.com <mailto:
> boards@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 <ra...@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
> >>
> >
>
>
Re: Minimum Java version for Log4j 2 3.0?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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 <boards@gmail.com <ma...@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 <ra...@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
>>
>
Re: Minimum Java version for Log4j 2 3.0?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ra...@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
>
Re: Minimum Java version for Log4j 2 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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
Re: Minimum Java version for Log4j 2 3.0?
Posted by Gary Gregory <ga...@gmail.com>.
The main hurdle for my day job is that Java 11 is not supported on all
hardware platforms yet, specifically, some of our customers run our apps on
IBM i/Series. That should not stop Log4j 3 to require Java 11 of course.
It's just one data point. To make the migration even slower, even when Java
11 makes it to the i/Series, that will require some OS level that not
everyone will be using, but it's too early for worry about that yet.
Gary
On Sat, Nov 7, 2020 at 6:38 PM Ralph Goers <ra...@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
>