Jackson V3 - Use JDK 11/17 as the minimum required

[GedMarc]

Is your feature request related to a problem? Please describe.
The movement of JDK's is accelerating, with a 460% increase in adoption of JDK 17 for the period 2022/2023.
JDK 8 EOL is getting to a decade out of date

Describe the solution you'd like
Is it possible to mark Jackson v3 for JDK 11, or JDK 17 as a base? As an example, Guice and other providers are setting the minimum JDK's, and compatibility is being affected having a build of JDK 8

Usage example
For JDK 11, no updates are necessary, as the test project (jackson-jdk11-test) compiles cleanly,
For JDK 17, there may be updates required to conform to the strict encapsulation requirements of the JDK

Additional context
Should be a simple switch to the source/target/ and release compiler flags in the POM

Relates to
FasterXML/jackson-modules-base#209

[cowtowncoder]

Yes, this would make sense. One possibility would be to start by going to JDK 11 now, make sure things work. And then see what is needed for JDK 17.

Reason I like going to 17 is that Record support could be simplified quite a bit, probably.

[GedMarc]

Well 11 is EOL in September.... I'm definitely routing for JDK 17 <3

I've been using 2.x on JDK 17 Quarkus and standalone JLink for a while now, but I don't really have any edge cases

[cowtowncoder]

Let's go to JDK 11 first nonetheless. I am not opposed to 17 but there's no real hurry.

[pjfanning]

Java 8 is still well supported - see https://en.wikipedia.org/wiki/Java_version_history

[cowtowncoder]

@pjfanning Yes, for historical reasons Java 8 is supported longer than many later versions. Plus since transition from 8 to 9 is such a big shift.

Still, by the time Jackson 3.0 is ready I think we are probably ready to move on.
This also possibly allows 2.x to remain with Java 8 baseline indefinitely.

[GedMarc]

@pjfanning See https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Support officially ended for JDK 8 March 2022, only corporate enterprises with valid licenses are still supported on an extended life span, when paid for - and even then it is only as a life line
All other JDK 8 are split off from other vendors, to manage support for users of Java without a commercial license

For the standard Java developer, JDK 8 is effectively canned?

[pjfanning]

Oracle are not the only Java Runtime providers. Adoptium and Azul Zulu, among others are very good alternatives. https://en.wikipedia.org/wiki/Java_version_history is well maintained.

[GedMarc]

It is, but it's also legacy money making :) Wikipedia also isn't a valid source for anything really?
The creators of Java dropped JDK 8 in 2017,

By that logic, GraalVM on JDK 7 is still supported and we shouldn't have bumped to JDK 8, even though Oracle killed it offwith commerical support ages ago.... The argument for alternative vendor support makes no sense when JDK's reach EOL, it is for enterprise support to assist in keeping legacy software operational - but it is still legacy software

[JooHyukKim]

+1 for "at least" JDK because....

• Transitive dependency reasons. Take Spring Boot having JDK 17 as baseline for example.(link) (though Spring is such controversial example 😂.)
• JDK development is so fast that we should also prepare what's ahead of us. Like make the architecture more flexible etc... who can assure that another record class type of "innovation" won't come?
• Legacy projects won't be upgrading their JDK anyway.

[cowtowncoder]

Close in favor of #4820.