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ı <vol...@yazi.ci> 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 <https://github.com/JCTools/JCTools/blob/master/pom.xml#L167>,
>   Guava <https://github.com/google/guava/blob/master/pom.xml#L113>, 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 <piotr.karw...@gmail.com>
> wrote:
> 
>> Hi Volkan,
>> 
>> On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı <vol...@yazi.ci> 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
>> 

Reply via email to