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
