You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2022/06/12 11:12:48 UTC
Compile `release-2.x` with JDK 11
Hi all,
Currently the `release-2.x` branch must be run using JDK 8 and uses
Maven's toolchains to compile Java 9+ code. This has many drawbacks:
* It is difficult for new contributors to run the build process,
* It requires a change to `JAVA_HOME` each time we build
`release-2.x`. I suppose most of you use a different default Java
version,
* the latest Maven Surefire plugin fails to run if there are Java 9+
classes on the classpath: it performs a class scan in the current JVM
and forks only afterwards.
From my own tests the `--release 8` switch on JDK 9+ works quite well
(i.e. the signatures of the JRE methods are those from JRE 8, not JRE
9+, the classes use the correct bytecode version and it produces
errors if we use Java 9+ language features). Maybe we could switch to
compiling `release-2.x` using Java 11 with the `--release 8` after
2.18.0 is out? I would keep the toolchains configuration exclusively
for the Maven Surefire plugin: it would scan the test classes using
the current JVM and fork an authentic JVM 8 to run the tests. What do
you think?
Piotr
Re: Compile `release-2.x` with JDK 11
Posted by Andrew Marlow <ma...@gmail.com>.
On Sun, 12 Jun 2022 at 12:13, Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi all,
>
> Currently the `release-2.x` branch must be run using JDK 8 and uses
> Maven's toolchains to compile Java 9+ code.
[snip]
Maybe we could switch to
> compiling `release-2.x` using Java 11 with the `--release 8` after
> 2.18.0 is out? I would keep the toolchains configuration exclusively
> for the Maven Surefire plugin: it would scan the test classes using
> the current JVM and fork an authentic JVM 8 to run the tests. What do
> you think?
>
> Piotr
>
sounds good to me. I reckon this will give log4j2 a longer lease of life
which will be very important for people who have moved there from log4j-v1
and don't want to go near log4j3 for a long time yet. Also I am sure many
projects will be on jdk-8 for quite some time yet.
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
Re: Compile `release-2.x` with JDK 11
Posted by Tim Perry <ti...@gmail.com>.
Yes, that looks like it would address my concern. Thank you.
> On Jun 12, 2022, at 11:43 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Can't we perform this check via configuring animal-sniffer-maven-plugin
> <https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin> to
> work with the `java18` signature
> <https://mvnrepository.com/artifact/org.codehaus.mojo.signature/java18>?
>
>> On Sun, Jun 12, 2022 at 8:32 PM Tim Perry <ti...@gmail.com> wrote:
>>
>> I've run into an issue where javac 11+ will emit valid java 8 code for
>> functions that weren't added to Java until after java 8. When the code is
>> run on Java 8 runtime errors appear complaining about functions missing
>> from classes that are part of the JRE. Most recently I ran into this when I
>> used java.lang.String@strip() in a library cross-compiled to java 8
>> bytecode with Java 11 javac.
>>
>> As long as there is some method to prevent the compiler from emitting code
>> that won't work on Java 8, I don't see a reason to compile with Java 8.
>> However, if this issue can't be prevented, then I think moving to Java 9+
>> will result in the accidental release of code that won't work on Java 8.
>>
>> FWIW, I haven't compiled with anything but Java 11+ for the last year and a
>> half. It is possible more recent versions of the java compiler warn you if
>> you use functions or maybe there is a maven plugin that would help here.
>>
>>
>>> On Sun, Jun 12, 2022 at 6:24 PM Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>
>>> Using a recent JDK, yet targeting 8 is a great idea Piotr! I brought up
>>> this subject a couple of times in the video calls, though, as far as I
>>> recall, the excuse was mostly the fact that Java 11 work is aimed for 3.x
>>> and the lack of time.
>>>
>>> Personally, I would even favor using Java 17 and configuring the target
>> for
>>> both `release-2.x` and `master`. In particular, JEP 355 (Text Blocks)
>>> released in Java 13 can help us to replace the XML configuration files in
>>> tests and hardcode them into the code.
>>>
>>> I also totally agree with the point of Andrew Marlow that using a modern
>>> JDK for 2.x will significantly decrease the maintenance burden.
>>>
>>> On Sun, Jun 12, 2022 at 1:13 PM Piotr P. Karwasz <
>> piotr.karwasz@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently the `release-2.x` branch must be run using JDK 8 and uses
>>>> Maven's toolchains to compile Java 9+ code. This has many drawbacks:
>>>> * It is difficult for new contributors to run the build process,
>>>> * It requires a change to `JAVA_HOME` each time we build
>>>> `release-2.x`. I suppose most of you use a different default Java
>>>> version,
>>>> * the latest Maven Surefire plugin fails to run if there are Java 9+
>>>> classes on the classpath: it performs a class scan in the current JVM
>>>> and forks only afterwards.
>>>>
>>>> From my own tests the `--release 8` switch on JDK 9+ works quite well
>>>> (i.e. the signatures of the JRE methods are those from JRE 8, not JRE
>>>> 9+, the classes use the correct bytecode version and it produces
>>>> errors if we use Java 9+ language features). Maybe we could switch to
>>>> compiling `release-2.x` using Java 11 with the `--release 8` after
>>>> 2.18.0 is out? I would keep the toolchains configuration exclusively
>>>> for the Maven Surefire plugin: it would scan the test classes using
>>>> the current JVM and fork an authentic JVM 8 to run the tests. What do
>>>> you think?
>>>>
>>>> Piotr
>>>>
>>>
>>
Re: Compile `release-2.x` with JDK 11
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Can't we perform this check via configuring animal-sniffer-maven-plugin
<https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin> to
work with the `java18` signature
<https://mvnrepository.com/artifact/org.codehaus.mojo.signature/java18>?
On Sun, Jun 12, 2022 at 8:32 PM Tim Perry <ti...@gmail.com> wrote:
> I've run into an issue where javac 11+ will emit valid java 8 code for
> functions that weren't added to Java until after java 8. When the code is
> run on Java 8 runtime errors appear complaining about functions missing
> from classes that are part of the JRE. Most recently I ran into this when I
> used java.lang.String@strip() in a library cross-compiled to java 8
> bytecode with Java 11 javac.
>
> As long as there is some method to prevent the compiler from emitting code
> that won't work on Java 8, I don't see a reason to compile with Java 8.
> However, if this issue can't be prevented, then I think moving to Java 9+
> will result in the accidental release of code that won't work on Java 8.
>
> FWIW, I haven't compiled with anything but Java 11+ for the last year and a
> half. It is possible more recent versions of the java compiler warn you if
> you use functions or maybe there is a maven plugin that would help here.
>
>
> On Sun, Jun 12, 2022 at 6:24 PM Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> > Using a recent JDK, yet targeting 8 is a great idea Piotr! I brought up
> > this subject a couple of times in the video calls, though, as far as I
> > recall, the excuse was mostly the fact that Java 11 work is aimed for 3.x
> > and the lack of time.
> >
> > Personally, I would even favor using Java 17 and configuring the target
> for
> > both `release-2.x` and `master`. In particular, JEP 355 (Text Blocks)
> > released in Java 13 can help us to replace the XML configuration files in
> > tests and hardcode them into the code.
> >
> > I also totally agree with the point of Andrew Marlow that using a modern
> > JDK for 2.x will significantly decrease the maintenance burden.
> >
> > On Sun, Jun 12, 2022 at 1:13 PM Piotr P. Karwasz <
> piotr.karwasz@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > Currently the `release-2.x` branch must be run using JDK 8 and uses
> > > Maven's toolchains to compile Java 9+ code. This has many drawbacks:
> > > * It is difficult for new contributors to run the build process,
> > > * It requires a change to `JAVA_HOME` each time we build
> > > `release-2.x`. I suppose most of you use a different default Java
> > > version,
> > > * the latest Maven Surefire plugin fails to run if there are Java 9+
> > > classes on the classpath: it performs a class scan in the current JVM
> > > and forks only afterwards.
> > >
> > > From my own tests the `--release 8` switch on JDK 9+ works quite well
> > > (i.e. the signatures of the JRE methods are those from JRE 8, not JRE
> > > 9+, the classes use the correct bytecode version and it produces
> > > errors if we use Java 9+ language features). Maybe we could switch to
> > > compiling `release-2.x` using Java 11 with the `--release 8` after
> > > 2.18.0 is out? I would keep the toolchains configuration exclusively
> > > for the Maven Surefire plugin: it would scan the test classes using
> > > the current JVM and fork an authentic JVM 8 to run the tests. What do
> > > you think?
> > >
> > > Piotr
> > >
> >
>
Re: Compile `release-2.x` with JDK 11
Posted by Tim Perry <ti...@gmail.com>.
Piotr,
It looks like the following will add the release flag to builds on Java 9+
but still work with Java 8. Should we use this?
<profile>
<id>java-8-api</id>
<activation>
<jdk>[9,)</jdk>
</activation>
<properties>
<maven.compiler.release>8</maven.compiler.release>
</properties></profile>
On Sun, Jun 12, 2022 at 10:16 PM Matt Sicker <bo...@gmail.com> wrote:
> Just see some of the commits in master that made that buildable in newer
> JDKs for ideas on what things need to be updated in 2.x for similar
> convenience. I’m not so sure about the release process requiring Java 11,
> but I’d support having this offered for convenience. Really, any build
> enhancements that makes the 2.x branch maintainable while 3.x becomes the
> new current will be great since I assume we’d all like to continue
> maintaining bug fixes and such for 2.x for a few years at least.
>
> —
> Matt Sicker
>
> > On Jun 12, 2022, at 16:47, Tim Perry <ti...@gmail.com> wrote:
> >
> > Piotr,
> >
> > I did a troll back through the history of the maven artifact in question
> > and I can see one of the admins removed the following line from the
> pom.xml
> > because it broke compilation with Java 8:
> >
> > <maven.compiler.release>8</maven.compiler.release>
> >
> > As you correctly guessed, this meant API compatibility wasn't checked
> when
> > building with Java 11 and explains what went wrong. Thanks for reminding
> me
> > what the issue was. Sorry to have brought this up, but I suppose we are
> > better safe than sorry.
> >
> > Happy Sunday.
> > Tim
> >
> >
> >> On Sun, Jun 12, 2022 at 8:26 PM Piotr P. Karwasz <
> piotr.karwasz@gmail.com>
> >> wrote:
> >>
> >> Hi Tim,
> >>
> >>> On Sun, 12 Jun 2022 at 20:32, Tim Perry <ti...@gmail.com> wrote:
> >>> I've run into an issue where javac 11+ will emit valid java 8 code for
> >>> functions that weren't added to Java until after java 8. When the code
> is
> >>> run on Java 8 runtime errors appear complaining about functions missing
> >>> from classes that are part of the JRE. Most recently I ran into this
> >> when I
> >>> used java.lang.String@strip() in a library cross-compiled to java 8
> >>> bytecode with Java 11 javac.
> >>
> >> Are you sure that the library was compiled with `--release 8` and not
> >> with `-source 8 -target 8`? `String#strip()` does not compile on my
> >> JDK 11, as well as `ByteBuffer#position(int)` uses the correct return
> >> type of `Buffer` (JRE 8) instead of `ByteBuffer` (JRE 11).
> >>
> >> Piotr
> >>
>
Re: Compile `release-2.x` with JDK 11
Posted by Matt Sicker <bo...@gmail.com>.
Just see some of the commits in master that made that buildable in newer JDKs for ideas on what things need to be updated in 2.x for similar convenience. I’m not so sure about the release process requiring Java 11, but I’d support having this offered for convenience. Really, any build enhancements that makes the 2.x branch maintainable while 3.x becomes the new current will be great since I assume we’d all like to continue maintaining bug fixes and such for 2.x for a few years at least.
—
Matt Sicker
> On Jun 12, 2022, at 16:47, Tim Perry <ti...@gmail.com> wrote:
>
> Piotr,
>
> I did a troll back through the history of the maven artifact in question
> and I can see one of the admins removed the following line from the pom.xml
> because it broke compilation with Java 8:
>
> <maven.compiler.release>8</maven.compiler.release>
>
> As you correctly guessed, this meant API compatibility wasn't checked when
> building with Java 11 and explains what went wrong. Thanks for reminding me
> what the issue was. Sorry to have brought this up, but I suppose we are
> better safe than sorry.
>
> Happy Sunday.
> Tim
>
>
>> On Sun, Jun 12, 2022 at 8:26 PM Piotr P. Karwasz <pi...@gmail.com>
>> wrote:
>>
>> Hi Tim,
>>
>>> On Sun, 12 Jun 2022 at 20:32, Tim Perry <ti...@gmail.com> wrote:
>>> I've run into an issue where javac 11+ will emit valid java 8 code for
>>> functions that weren't added to Java until after java 8. When the code is
>>> run on Java 8 runtime errors appear complaining about functions missing
>>> from classes that are part of the JRE. Most recently I ran into this
>> when I
>>> used java.lang.String@strip() in a library cross-compiled to java 8
>>> bytecode with Java 11 javac.
>>
>> Are you sure that the library was compiled with `--release 8` and not
>> with `-source 8 -target 8`? `String#strip()` does not compile on my
>> JDK 11, as well as `ByteBuffer#position(int)` uses the correct return
>> type of `Buffer` (JRE 8) instead of `ByteBuffer` (JRE 11).
>>
>> Piotr
>>
Re: Compile `release-2.x` with JDK 11
Posted by Tim Perry <ti...@gmail.com>.
Piotr,
I did a troll back through the history of the maven artifact in question
and I can see one of the admins removed the following line from the pom.xml
because it broke compilation with Java 8:
<maven.compiler.release>8</maven.compiler.release>
As you correctly guessed, this meant API compatibility wasn't checked when
building with Java 11 and explains what went wrong. Thanks for reminding me
what the issue was. Sorry to have brought this up, but I suppose we are
better safe than sorry.
Happy Sunday.
Tim
On Sun, Jun 12, 2022 at 8:26 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Tim,
>
> On Sun, 12 Jun 2022 at 20:32, Tim Perry <ti...@gmail.com> wrote:
> > I've run into an issue where javac 11+ will emit valid java 8 code for
> > functions that weren't added to Java until after java 8. When the code is
> > run on Java 8 runtime errors appear complaining about functions missing
> > from classes that are part of the JRE. Most recently I ran into this
> when I
> > used java.lang.String@strip() in a library cross-compiled to java 8
> > bytecode with Java 11 javac.
>
> Are you sure that the library was compiled with `--release 8` and not
> with `-source 8 -target 8`? `String#strip()` does not compile on my
> JDK 11, as well as `ByteBuffer#position(int)` uses the correct return
> type of `Buffer` (JRE 8) instead of `ByteBuffer` (JRE 11).
>
> Piotr
>
Re: Compile `release-2.x` with JDK 11
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Tim,
On Sun, 12 Jun 2022 at 20:32, Tim Perry <ti...@gmail.com> wrote:
> I've run into an issue where javac 11+ will emit valid java 8 code for
> functions that weren't added to Java until after java 8. When the code is
> run on Java 8 runtime errors appear complaining about functions missing
> from classes that are part of the JRE. Most recently I ran into this when I
> used java.lang.String@strip() in a library cross-compiled to java 8
> bytecode with Java 11 javac.
Are you sure that the library was compiled with `--release 8` and not
with `-source 8 -target 8`? `String#strip()` does not compile on my
JDK 11, as well as `ByteBuffer#position(int)` uses the correct return
type of `Buffer` (JRE 8) instead of `ByteBuffer` (JRE 11).
Piotr
Re: Compile `release-2.x` with JDK 11
Posted by Tim Perry <ti...@gmail.com>.
I've run into an issue where javac 11+ will emit valid java 8 code for
functions that weren't added to Java until after java 8. When the code is
run on Java 8 runtime errors appear complaining about functions missing
from classes that are part of the JRE. Most recently I ran into this when I
used java.lang.String@strip() in a library cross-compiled to java 8
bytecode with Java 11 javac.
As long as there is some method to prevent the compiler from emitting code
that won't work on Java 8, I don't see a reason to compile with Java 8.
However, if this issue can't be prevented, then I think moving to Java 9+
will result in the accidental release of code that won't work on Java 8.
FWIW, I haven't compiled with anything but Java 11+ for the last year and a
half. It is possible more recent versions of the java compiler warn you if
you use functions or maybe there is a maven plugin that would help here.
On Sun, Jun 12, 2022 at 6:24 PM Volkan Yazıcı <vo...@yazi.ci> wrote:
> Using a recent JDK, yet targeting 8 is a great idea Piotr! I brought up
> this subject a couple of times in the video calls, though, as far as I
> recall, the excuse was mostly the fact that Java 11 work is aimed for 3.x
> and the lack of time.
>
> Personally, I would even favor using Java 17 and configuring the target for
> both `release-2.x` and `master`. In particular, JEP 355 (Text Blocks)
> released in Java 13 can help us to replace the XML configuration files in
> tests and hardcode them into the code.
>
> I also totally agree with the point of Andrew Marlow that using a modern
> JDK for 2.x will significantly decrease the maintenance burden.
>
> On Sun, Jun 12, 2022 at 1:13 PM Piotr P. Karwasz <pi...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > Currently the `release-2.x` branch must be run using JDK 8 and uses
> > Maven's toolchains to compile Java 9+ code. This has many drawbacks:
> > * It is difficult for new contributors to run the build process,
> > * It requires a change to `JAVA_HOME` each time we build
> > `release-2.x`. I suppose most of you use a different default Java
> > version,
> > * the latest Maven Surefire plugin fails to run if there are Java 9+
> > classes on the classpath: it performs a class scan in the current JVM
> > and forks only afterwards.
> >
> > From my own tests the `--release 8` switch on JDK 9+ works quite well
> > (i.e. the signatures of the JRE methods are those from JRE 8, not JRE
> > 9+, the classes use the correct bytecode version and it produces
> > errors if we use Java 9+ language features). Maybe we could switch to
> > compiling `release-2.x` using Java 11 with the `--release 8` after
> > 2.18.0 is out? I would keep the toolchains configuration exclusively
> > for the Maven Surefire plugin: it would scan the test classes using
> > the current JVM and fork an authentic JVM 8 to run the tests. What do
> > you think?
> >
> > Piotr
> >
>
Re: Compile `release-2.x` with JDK 11
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Using a recent JDK, yet targeting 8 is a great idea Piotr! I brought up
this subject a couple of times in the video calls, though, as far as I
recall, the excuse was mostly the fact that Java 11 work is aimed for 3.x
and the lack of time.
Personally, I would even favor using Java 17 and configuring the target for
both `release-2.x` and `master`. In particular, JEP 355 (Text Blocks)
released in Java 13 can help us to replace the XML configuration files in
tests and hardcode them into the code.
I also totally agree with the point of Andrew Marlow that using a modern
JDK for 2.x will significantly decrease the maintenance burden.
On Sun, Jun 12, 2022 at 1:13 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi all,
>
> Currently the `release-2.x` branch must be run using JDK 8 and uses
> Maven's toolchains to compile Java 9+ code. This has many drawbacks:
> * It is difficult for new contributors to run the build process,
> * It requires a change to `JAVA_HOME` each time we build
> `release-2.x`. I suppose most of you use a different default Java
> version,
> * the latest Maven Surefire plugin fails to run if there are Java 9+
> classes on the classpath: it performs a class scan in the current JVM
> and forks only afterwards.
>
> From my own tests the `--release 8` switch on JDK 9+ works quite well
> (i.e. the signatures of the JRE methods are those from JRE 8, not JRE
> 9+, the classes use the correct bytecode version and it produces
> errors if we use Java 9+ language features). Maybe we could switch to
> compiling `release-2.x` using Java 11 with the `--release 8` after
> 2.18.0 is out? I would keep the toolchains configuration exclusively
> for the Maven Surefire plugin: it would scan the test classes using
> the current JVM and fork an authentic JVM 8 to run the tests. What do
> you think?
>
> Piotr
>