You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 #4820
My opinion is that libs ideally support the max number of Java versions. Multi-Release jar support is there to help us optimise support for different Java versions.
I would prefer not having to use MR for anything, personally. But if we must for something I guess we can try figuring it out.
But even if we do, we need to set up minimum baseline and I think Java 8 should be left for Jackson 2.x. So the question remains.
But let's have discussion/vote on
changed the title [-]Change JDK baseline for Jackson 3.0 from Java 8 to Java 21 (?)[/-][+]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 or 21 (?)[/+]on Dec 1, 2024
Quick suggestion: unless anyone objects, I could work on increasing baseline first to JDK 17 (wrt CI). And then if (but only if) decision is made to go to JDK 21 make further changes. This allows finding possible issues wrt change of baseline and tackling most of complexity, regardless of the ultimate decision on exact baseline JDK to use.
changed the title [-]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 or 21 (?)[/-][+]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17[/+]on Dec 3, 2024
Note: discussion FasterXML/jackson-future-ideas#73 is now closed and JDK 17 was chosen as the baseline (over JDK 21). So changes under this issue are sufficient as-is.
Activity
pjfanning commentedon Dec 1, 2024
My opinion is that libs ideally support the max number of Java versions. Multi-Release jar support is there to help us optimise support for different Java versions.
JooHyukKim commentedon Dec 1, 2024
Found dup issue #3946
JooHyukKim commentedon Dec 1, 2024
Which JDK version do you have in mind, with multi-release jar strategy @pjfanning?
cowtowncoder commentedon Dec 1, 2024
I would prefer not having to use MR for anything, personally. But if we must for something I guess we can try figuring it out.
But even if we do, we need to set up minimum baseline and I think Java 8 should be left for Jackson 2.x. So the question remains.
But let's have discussion/vote on
FasterXML/jackson-future-ideas#73
[-]Change JDK baseline for Jackson 3.0 from Java 8 to Java 21 (?)[/-][+]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 or 21 (?)[/+]cowtowncoder commentedon Dec 1, 2024
Quick suggestion: unless anyone objects, I could work on increasing baseline first to JDK 17 (wrt CI). And then if (but only if) decision is made to go to JDK 21 make further changes. This allows finding possible issues wrt change of baseline and tackling most of complexity, regardless of the ultimate decision on exact baseline JDK to use.
cowtowncoder commentedon Dec 2, 2024
Note on work for initial JDK 17 update (which may or may not be the last change, depending on discussions)
Core
Jackson-jr
Data formats
Data types
Other modules
JVM langs:
Providers
maxandersen commentedon Dec 2, 2024
Go for 17 please otherwise Quarkus, spring and lots of others will be stuck on older Jackson and we'll be all stuck maintaining old code.
Unless you know of some specific feature in java 21 that Jackson just can't function without and not support from Java 17 then please go for 17.
JooHyukKim commentedon Dec 2, 2024
Your vote + opinion on FasterXML/jackson-future-ideas#73 would be great @maxandersen !
[-]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 or 21 (?)[/-][+]Change JDK baseline for Jackson 3.0 from Java 8 to Java 17[/+]Fix #4820: Change JDK baseline for Jackson 3.0 from Java 8 to Java 17
JooHyukKim commentedon Dec 3, 2024
Data types
Fix #4820: Change JDK baseline for Jackson 3.0 from Java 8 to Java 17 (…
cowtowncoder commentedon Dec 5, 2024
Completed.
cowtowncoder commentedon Jan 3, 2025
Note: discussion FasterXML/jackson-future-ideas#73 is now closed and JDK 17 was chosen as the baseline (over JDK 21). So changes under this issue are sufficient as-is.