[MRESOLVER-671] Don't require Java 21

[jira-importer]

Elliotte Rusty Harold opened MRESOLVER-671 and commented

Apparently maven-resolver now requires Java 21 to build. It won't build even with Java 17. This is getting inconveniently out of sync with what devs have installed. E.g we can't even jdeprscan for Java 11 or 8 with this version. This should be pushed back to 17 or further if possible. The bleeding edge is too bloody.

---

No further details from MRESOLVER-671

[jira-importer]

Elliotte Rusty Harold commented

Also worth noting that Java 21 breaks PMD. That is, it requires us not to scan this project with PMD.

[jira-importer]

Piotr Zygielo commented

Also worth noting that Java 21 breaks PMD. That is, it requires us not to scan this project with PMD.

Could you clarify? PMD works fine with Java 21. And PMD with Java 21 scans the Resolver fine (for the value of {}now{}=b86272939310235a38c6364aef9fe23167e3dd73).

[jira-importer]

Tamas Cservenak commented

I disagree, Java 21 is latest LTS (and is not bloody bleeding edge, that would be 23.0.2 in this moment). Again build time requirement of 'latest LTS' just makes sense, as every developer I know do have 'latest LTS'.
While Resolver 2.x (output) is said to be Java 8, you have to notice two things:

• Thee is parked Move to Java17 #438 (to align with Maven4)
• Many new functionalities (like JDK transport) are NOT Java 8, but 11+, but are done as MR JARs to have them work in Java 8 as well (JDK transport in Java 8 just reports "no transport").
• But, I decided to keep Resolver 2.0.x at Java 8 for one reason (and lift Java to 17+ in 2.1.x or so): having it as such, keeps our options open for Maven 3.10.x with Resolver 2.0.x -- not something I plan, I just like to have options open if possible.

[jira-importer]

Tamas Cservenak commented

I never understood this "requirement for non bloody edge Java", as you do not insist on using OS that is from times when Maven3 was incepted, do you? We all use latest modern OS and IMO for the very same reason we should use latest moden Java and other tool versions as well, and this is totally unrelated to "--release 8" compiler flag (to the fact that stuff we are building on modern OS with modern Java is specd to "runs on Java 8").

[jira-importer]

Elliotte Rusty Harold commented

I rarely use the latest OS. I rarely use the latest Java. And wrt Java that's the posture of the vast majority of organizations I've ever encountered, Meta and Google included. The devs I notice using the latest LTS JDK are individual cowboy developers. The large organizations where most developers work most of the time do not run or build with the latest LTS.

I no longer have access to the current statistics Google collects about what its customers want (a broader and more accurate sample than I've seen elsewhere) but when I did the pattern was clear. The latest LTS was extremely rare. Second to latest was present but not the majority. Third latest was probably a plurality, and there was a long and thick tail of older versions.

Non-LTS releases were a drop in the bucket except for JDKs before LTS was a thing (i.e. Java 1.7 and earlier) and these we saw a shocking number of.

[jira-importer]

Elliotte Rusty Harold commented

As to PMD see here in the code: https://github.com/apache/maven-resolver/blob/master/pom.xml#L123

 

    <!-- site fixes: skip PMD as it does not support Java 21 -->
    <pmd.skip>true</pmd.skip>

[jira-importer]

Piotr Zygielo commented

#653

[jira-importer]

Tamas Cservenak commented

That comment was added two years ago by me, then PMD had issues, that were fixed since then. Again. "tooling had to be updated", nothing more.

[jira-importer]

Elliotte Rusty Harold commented

Also, w.r.t the bleeding edge, I think there's an industry-wide failure to calculate and sum the cost of forcing upgrades on users. It's an externality. Hardly unique to Maven or Java. As one example, yesterday I blew an hour trying to install JDK 21 on my laptop just to build the resolver. I still don't have a working JDK 21 installed, but somehow ended up with JDK 23. No idea how that happened, but it seems to work so I stopped. Still doesn't work in IntelliJ though. Fixing that would probably cost another hour.

[jira-importer]

Michael Osipov commented

I fully agree with Elliotte Rusty Harold regarding the unnecessary high bar.

[jira-importer]

Tamas Cservenak commented

I find so many self contradicting things... who are "users" that are forced on upgrades? You?
I disagree about the "high bar" as well, why you insist on living in past?
Maven4 is not yet even released (GA), and when it MAY be released, we MAY have already the next Java LTS out.
And you want to go backwards?

In fact, I see folks like you the problem: if all users would use "latest" LTS (assume they would somehow manage to get it installed), we'd not have issues that we currently have, to support building projects on wildly different Java versions, from Java 8 to Java 21, spotless comes to my mind, just to mention one issue.

Remember this?
https://lists.apache.org/thread/ors31h7cbn6q777f8j9nkzp8x3p0b4nf

[jira-importer]

Tamas Cservenak commented

For me, all this your are for comes from a bad reflex that for some reason became norm among Maven users (and it seems devs as well):
"you should build the project using the Java version that project targets" (or in other words, if we build Java 8 stuff, let's use Java 8 to build it).

Corollary:
if you use build a native app that supports Win95, it is expectation to have it built on Win95.

[jira-importer]

Elliotte Rusty Harold commented

It's not just my MacBook. It's every MacBook and Linux system at Google, and Meta, and many other places with developers who are willing and able to contribute to Maven. It's the internal build systems that bulld all the open source from scratch.

Large organizations standardize tooling including the JDK for good reason. Setting up separate tool paths for external and internal development  is a major inconvenience. 

The bad reflex I see is that newer JDKs are better. That's an unproven assertion. It often isn't true. There've been some nice additions to the libraries, and a lot in the runtime, but these are counter-balanced by some actively bad additions to the language.

[jira-importer]

Elliotte Rusty Harold commented

And let me just quote what I said in the thread you cite:

 
I think that's likely to produce far more weird, hard-to-debug
breakages of Maven on end users' machines. IMHO we are already far too
aggressive in what we consider supported. The enterprise and big tech
world simply does not upgrade that fast. For instance, 3.5.0 is what I
had on my day job machine because that's what the package manager
installs in 2023, not because it's the version I picked.

There is a clear distinction between Maven itself and the plugins and
libraries pulled in via a pom.xml. Maven is a tool installed on end
users machines and is years out of date in many cases. Libraries
published for consumption by builds through declarations in the
pom.xml, and this includes plugins, should not be tightly coupled to
the versions of tools installed on end user systems such as mvn and
the JDK. It's the robustness principle in action, be conservative in
what you send, be liberal in what you accept.

[jira-importer]

Tamas Cservenak commented

I think you are conflating things here. I really understand that some companies have very conservative stance regarding their tools, but also you should understand that others do not. Moreover, this is an open source project, so unsure why should we apply anyones policy to it, nor am unsure why do you expect that same toolset you use or used in some company "should work" for this project as well (like "it must work as I used this on my work too"). Don't conflate your daily work and your OSS contribution, that's all.

In fact, some devs really think about this whole project "as if it would be a company". Well, it is not. We have no managers, no schedules, no trainees nor secretaries and so on and so on. Do not bring your working habits here, and especially do not try to force them on others. And this is not only about toolset you want to use, but also general remark about using forks or not, polluting canonical repository with private branches (named in such way, to not reveal any clue what it is about, or issue it tries to fix), etc. I understand the "this is how i used to work at ACME Corp" sentiment, but please understand: this is not ACME Corp.