Its more about supporting an ancient JVM/JDK than compiling Maven on an
ancient version. So as long as Maven targets 8 or less in its build, I don't
think anyone cares (at least I don't) what the actual version of the JDK you
use in the build pipeline. Go ahead and have a source setting of 17 and a
target setting of 8 and as long as it works, I'm fine with it.
Other possible reasons are licensing changes after Java 8 can be a concern for
some companies (I don't know enough about the law to know if that is a good
reason or not). There are some poor souls out there that have really ancient
setups from 20 years ago and trying to get those working on Java 9+ can be
challenging. That's really the big reason people have an opinion on this.
Also, Java 8 is the last Sun version of Java. Some old folks still have strong
opinions on Oracle's ownership of Java. I'm not one of those folks.
Hunter
On Tuesday, February 20, 2024 at 08:52:20 PM PST, David Jencks
<david.a.jen...@gmail.com> wrote:
From your first paragraph I’d guess you would be on the “maven built on a
recent LTS java” side. I was wondering, given these omnipresent IDES, and
possibly from a philosophical perspective, what the arguments for “maven built
on an antique JVM” would be.
Thanks
David Jencks
> On Feb 20, 2024, at 8:10 PM, Hunter C Payne
> <hunterpayne2...@yahoo.com.INVALID> wrote:
>
> IDEs, including the 2 you named, have a configuration system for multiple
> JDKs. This allows devs to build for multiple versions of the JVM. Likewise,
> Maven has multiple ways to configure multiple JDKs for use by different
> phases or plugins used in a given compilation setup and to target different
> versions of the JVM. Javac can target any older version than itself when
> compiling to classfiles. So my JDK 17 can compile for Java 8-17 but not 18
> or higher.
>
> On the JVM, packaging is just a jar and inside that jar's classfiles will be
> a specific minimum version of the JVM required for it to run. Generally
> speaking, for a variety of reasons, most Java code is backwards compatible to
> Java 8 which was released about 15 years ago. No specific code is that
> backwards compatible but most of it is. That's why you don't realize that
> these things exist. Because unless you are a professional developer, why
> would you ever care in a language with 15 years of backwards compatibility
> baked into the culture and large base of 3rd party code. Hope this answers
> your question.
>
> Hunter
>
> On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks
><david.a.jen...@gmail.com> wrote:
>
> I’ve been wondering for some time… My uninformed impression is that most
> corporate development uses Eclipse or IntilliJ, which I believe run only on
> the java version they come packaged with, which presumably is not usually the
> target java version for the code being developed. Aside from packaging
> questions (IIUC there’s no way for the maven project to ship a java
> implementation), why should Maven be different?
>
> Thanks
> David Jencks
>
>> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák <ta...@cservenak.net> wrote:
>>
>> Romain,
>>
>> you immediately revealed your WHY:
>> Take off your "paid dev" hat, and please try again.
>>
>> We ARE an open source project.
>> So it IS about us, the volunteers.
>> Is not about THEM, downstream users.
>>
>> As it was told a million times:
>> if they are stuck (due whatever policy or who knows what), they can just
>> stay with 3.9, 3.8 or whatever suits them.
>> Why align with the "stuck" ones?
>>
>> T
>>
>> PS: and no, I just collected the last release VOTEs w/ Herve responses on
>> ML. If you consider that biased, then you have a problem ;)
>>
>>
>>
>> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>
>>>> I am sure the majority of Maven users do not run Maven on the same Java
>>> version they target with their build.
>>>
>>> Do you use that and the following figures to do a biased conclusion?
>>>
>>> "If people don't use the same version then we can higher the version"?
>>>
>>> I think we need to consider two things:
>>>
>>> * We are OSS dev so not representative of the majority - in a company you
>>> most of the time use the same version you target and want to run that, just
>>> either laziness, policy or quality (building with different versions can
>>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>>> to find data there but I'm pretty sure it is a common experience
>>> * Guess there is a "use the first matching version I have" in the stats you
>>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>>> you are ok to run 21 (random numbers, move them a bit to be a counter
>>> example on whatever digit you want for maven 4)
>>> * Guess very few people want to have >= 1 JDK
>>>
>>> So clearly the question is not the latest LTS which would be for me just a
>>> moving version we can't support and would be bad for our end users IMHO but
>>> only the version we pick to start at 4.0.0.
>>> Choices stay:
>>>
>>> * Latest LTS at that moment to start fresh and not inherit from a legacy at
>>> day 0
>>> * Latest LTS - 1 - which would enable to cover more projects and get more
>>> adoptions
>>> * Something older but I don't find any valid reason since people skipping 2
>>> LTS will likely never reach maven 4 before we discuss to move our baseline
>>> again.
>>>
>>> The other question we should probably anticipate is when do we move our
>>> support version range.
>>> Since java is not more predictable in terms of releases I think it can make
>>> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
>>> - indeed with best effort on later versions but no guarantee upfront.
>>> With such a policy calendar can be communicated and people can follow or
>>> not without surprises.
>>>
>>> So today, since we don't have yet a final I think 21 can make sense but not
>>> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
>>> time.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>
>>>
>>>
>>> Le mar. 20 févr. 2024 à 21:50, Tamás Cservenák <ta...@cservenak.net> a
>>> écrit :
>>>
>>>> Howdy,
>>>>
>>>> I intentionally used "Maven" here, and not "Maven 4" as I am sure the
>>>> majority of Maven users do not run Maven on the same Java version they
>>>> target with their build. We do not do that either.
>>>>
>>>> Some snippets from Herve (who is the ONLY one doing reproducible checks,
>>>> kudos for that) votes:
>>>>
>>>> Sun, Feb 18, 2024, 9:38 AM
>>>> [VOTE] Release Apache Maven Shade Plugin version 3.5.2
>>>> Reproducible Build ok: reference build done with JDK 11 on *nix
>>>>
>>>> Wed, Jan 31, 2024, 5:06 AM
>>>> [VOTE] Release Apache Maven JLink Plugin version 3.2.0
>>>> Reproducible Builds ok: reference build done on *nix with JDK 21 and
>>> umask
>>>> 022
>>>>
>>>> Mon, Jan 8, 2024, 8:29 AM
>>>> [VOTE] Release Maven Plugin Tools version 3.11.0
>>>> Reproducible Builds ok: reference build done with JDK 8 on Windows with
>>>> umask
>>>>
>>>> Mon, Dec 18, 2023, 8:59 AM
>>>> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
>>>> Reproducible Builds ok: reference build done on *nix with JDK 21 and
>>> umask
>>>> 022
>>>>
>>>> Mon, Dec 18, 2023, 8:59 AM
>>>> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
>>>> Reproducible Builds ok: reference build done on *nix with JDK 21 and
>>> umask
>>>> 022
>>>>
>>>> Wed, Nov 29, 2023, 8:16 AM
>>>> [VOTE] Apache Maven Build Cache Extension 1.1.0
>>>> Reproducible Build ok: reference build done on *nix with JDK 11
>>>>
>>>> Sun, Nov 19, 2023, 5:17 PM
>>>> [VOTE] Release Maven Resolver 1.9.17
>>>> Reproducible Build ok: reference build done with JDK 21 on *nix with
>>> umask
>>>> 022
>>>>
>>>> Sat, Oct 21, 2023, 4:34 PM
>>>> VOTE] Apache Maven 4.0.0-alpha-8 release
>>>> Reproducible Build ok: reference build done with JDK 21 on *nix with
>>> umask
>>>> 022
>>>>
>>>> Mon, Oct 2, 2023, 9:11 AM
>>>> [VOTE] Release Apache Maven 3.9.5
>>>> Reproducible not fully ok: reference build done with JDK 17 on *nix and
>>>> umask 022
>>>>
>>>> ====
>>>>
>>>> This CLEARLY shows the tendency:
>>>> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
>>>> and windows person :)
>>>> - Olivier used the "minimum" required Java version (for build cache).
>>>> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
>>>> use 21 but also 8, but he shot for 11 that was EOL at the moment of
>>>> release.
>>>> - The rest is 21.
>>>>
>>>> ====
>>>>
>>>> So, the question for those refusing anything other than Java 8 to _run_
>>>> Maven (or to revert: for those refusing to run Maven on "latest LTS",
>>> that
>>>> is currently 21):
>>>> WHY?
>>>>
>>>>
>>>> Thanks
>>>> T
>>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
