[log4j] Upgrade `main` compiler and runtime to Java 17

[Volkan Yazıcı]

I have just updated `main` to require Java 17 for compiling and to target
Java 17. Previously both were Java 11. If you have objections, please
discuss in this thread.

On Fri, Dec 1, 2023 at 10:42 PM Volkan Yazıcı  wrote:

> Done. Will port this to `main` next week.
>
> On Thu, Nov 30, 2023 at 5:03 PM Volkan Yazıcı  wrote:
>
>> Heads up! #2021 
>> bumps the `2.x` baseline to Java 17. Everything works locally. If CI agrees
>> too, I will merge it tomorrow and start porting to `main`.
>>
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
>
> I have just updated `main` to require Java 17 for compiling and to target
> Java 17. Previously both were Java 11. If you have objections, please
> discuss in this thread.

I am Ok with bumping the bytecode to Java 17.

Regarding the build requirements I would give by **default** a larger
spectrum of possible JDKs.
Right now we only accept JDK 17 in the default Maven profile. A Log4j
contributor is forced to install JDK 17 for a build to succeed, which
might be annoying. Therefore it might be better to:

 * set the Enforcer plugin to accept [minimum_JDK_required_by_Maven_plugins,)
 * set [17,18) **only** in the `release` plugin.

BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will be 17.

Piotr

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Gary Gregory]

I'm OK with Java 17 as the runtime minimum.

Gary

On Tue, Dec 5, 2023, 7:19 AM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
> >
> > I have just updated `main` to require Java 17 for compiling and to target
> > Java 17. Previously both were Java 11. If you have objections, please
> > discuss in this thread.
>
> I am Ok with bumping the bytecode to Java 17.
>
> Regarding the build requirements I would give by **default** a larger
> spectrum of possible JDKs.
> Right now we only accept JDK 17 in the default Maven profile. A Log4j
> contributor is forced to install JDK 17 for a build to succeed, which
> might be annoying. Therefore it might be better to:
>
>  * set the Enforcer plugin to accept
> [minimum_JDK_required_by_Maven_plugins,)
>  * set [17,18) **only** in the `release` plugin.
>
> BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
> be 17.
>
> Piotr
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Volkan Yazıcı]

I disagree with having an open-ended compiler baseline requirement due to

   1. It is not a minor task to bump the compiler version. The Java 17
   upgrade task was on hold already for several months due to its intricacies.
   As a matter of fact, you were the one who dropped the ball after the Java
   11 upgrade. (It was a rightful decision and I am glad you did the hard work
   of Java 11 upgrade. 🙇)
   2. Fixing the baseline will keep everybody (maintainers, individual
   contributors, etc.) on the same page due to no moving parts. Less "Are you
   using Java 17?"-kind questions while troubleshooting.
   3. Those who want to test Log4j against new JDKs still can easily:
   `-Denforcer.skip`
   4. `.java-version` doesn't support ranges (AFAIK)
   5. I don't find it annoying. On the contrary, several other major
   projects adopt this pattern: Spring Boot
   
,
   JUnit
   
,
   JCTools ,
   Guava , etc.
   6. I don't see a compelling use case.

All that said, I am not strongly opinionated about this and I wouldn't stop
you from replacing `[17,18)` with `[17,)` in `/pom.xml`.

On Tue, Dec 5, 2023 at 1:19 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
> >
> > I have just updated `main` to require Java 17 for compiling and to target
> > Java 17. Previously both were Java 11. If you have objections, please
> > discuss in this thread.
>
> I am Ok with bumping the bytecode to Java 17.
>
> Regarding the build requirements I would give by **default** a larger
> spectrum of possible JDKs.
> Right now we only accept JDK 17 in the default Maven profile. A Log4j
> contributor is forced to install JDK 17 for a build to succeed, which
> might be annoying. Therefore it might be better to:
>
>  * set the Enforcer plugin to accept
> [minimum_JDK_required_by_Maven_plugins,)
>  * set [17,18) **only** in the `release` plugin.
>
> BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
> be 17.
>
> Piotr
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Gary Gregory]

I could see us building and running on LTS versions only (17, 21) but not
anything else feels restrictive. Building on Java 21 will also let us avoid
trouble (maybe) with running on 21. IOW, I hope-wish for that GitHub builds
run and test on 17, 21, and 22-EA as a nice-to-have.

Gary


On Tue, Dec 5, 2023, 7:49 AM Volkan Yazıcı  wrote:

> I disagree with having an open-ended compiler baseline requirement due to
>
>1. It is not a minor task to bump the compiler version. The Java 17
>upgrade task was on hold already for several months due to its
> intricacies.
>As a matter of fact, you were the one who dropped the ball after the
> Java
>11 upgrade. (It was a rightful decision and I am glad you did the hard
> work
>of Java 11 upgrade. 🙇)
>2. Fixing the baseline will keep everybody (maintainers, individual
>contributors, etc.) on the same page due to no moving parts. Less "Are
> you
>using Java 17?"-kind questions while troubleshooting.
>3. Those who want to test Log4j against new JDKs still can easily:
>`-Denforcer.skip`
>4. `.java-version` doesn't support ranges (AFAIK)
>5. I don't find it annoying. On the contrary, several other major
>projects adopt this pattern: Spring Boot
><
> https://github.com/spring-projects/spring-boot/blob/main/buildSrc/build.gradle#L13
> >,
>JUnit
><
> https://github.com/junit-team/junit5/blob/main/gradle/plugins/settings.gradle.kts#L4
> >,
>JCTools ,
>Guava , etc.
>6. I don't see a compelling use case.
>
> All that said, I am not strongly opinionated about this and I wouldn't stop
> you from replacing `[17,18)` with `[17,)` in `/pom.xml`.
>
> On Tue, Dec 5, 2023 at 1:19 PM Piotr P. Karwasz 
> wrote:
>
> > Hi Volkan,
> >
> > On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
> > >
> > > I have just updated `main` to require Java 17 for compiling and to
> target
> > > Java 17. Previously both were Java 11. If you have objections, please
> > > discuss in this thread.
> >
> > I am Ok with bumping the bytecode to Java 17.
> >
> > Regarding the build requirements I would give by **default** a larger
> > spectrum of possible JDKs.
> > Right now we only accept JDK 17 in the default Maven profile. A Log4j
> > contributor is forced to install JDK 17 for a build to succeed, which
> > might be annoying. Therefore it might be better to:
> >
> >  * set the Enforcer plugin to accept
> > [minimum_JDK_required_by_Maven_plugins,)
> >  * set [17,18) **only** in the `release` plugin.
> >
> > BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
> > be 17.
> >
> > Piotr
> >
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Matt Sicker]

I think it makes sense to default to a supported version, and we can take a 
manual look at what’s required in updates as new Java versions come out rather 
than letting random users find out by accident.

> On Dec 5, 2023, at 6:49 AM, Volkan Yazıcı  wrote:
> 
> I disagree with having an open-ended compiler baseline requirement due to
> 
>   1. It is not a minor task to bump the compiler version. The Java 17
>   upgrade task was on hold already for several months due to its intricacies.
>   As a matter of fact, you were the one who dropped the ball after the Java
>   11 upgrade. (It was a rightful decision and I am glad you did the hard work
>   of Java 11 upgrade. 🙇)
>   2. Fixing the baseline will keep everybody (maintainers, individual
>   contributors, etc.) on the same page due to no moving parts. Less "Are you
>   using Java 17?"-kind questions while troubleshooting.
>   3. Those who want to test Log4j against new JDKs still can easily:
>   `-Denforcer.skip`
>   4. `.java-version` doesn't support ranges (AFAIK)
>   5. I don't find it annoying. On the contrary, several other major
>   projects adopt this pattern: Spring Boot
>   
> ,
>   JUnit
>   
> ,
>   JCTools ,
>   Guava , etc.
>   6. I don't see a compelling use case.
> 
> All that said, I am not strongly opinionated about this and I wouldn't stop
> you from replacing `[17,18)` with `[17,)` in `/pom.xml`.
> 
> On Tue, Dec 5, 2023 at 1:19 PM Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
>>> 
>>> I have just updated `main` to require Java 17 for compiling and to target
>>> Java 17. Previously both were Java 11. If you have objections, please
>>> discuss in this thread.
>> 
>> I am Ok with bumping the bytecode to Java 17.
>> 
>> Regarding the build requirements I would give by **default** a larger
>> spectrum of possible JDKs.
>> Right now we only accept JDK 17 in the default Maven profile. A Log4j
>> contributor is forced to install JDK 17 for a build to succeed, which
>> might be annoying. Therefore it might be better to:
>> 
>> * set the Enforcer plugin to accept
>> [minimum_JDK_required_by_Maven_plugins,)
>> * set [17,18) **only** in the `release` plugin.
>> 
>> BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
>> be 17.
>> 
>> Piotr
>>