[gaeljw]

Pull Request Checklist

• Have you read through the contributor guidelines?
• Have you squashed your commits?
• Have you added copyright headers to new files?
• Have you updated the documentation?
• Have you added tests for any changed functionality?

Fixes

Fixes #1258

Purpose

Upgrade Jackson from 2.x to 3.x.

Background Context

• build.sbt: I merged declaration of jackson-databind with the other Jackson dependencies, not sure why it was separate but there doesn't seem to be any reason anymore
• JacksonJson:
  • I had to change ObjectMapper to JsonMapper so that we can use .enable(JsonWriteFeature.ESCAPE_NON_ASCII) (not available on ObjectMapper as it's a JSON specific feature). This makes sense anyway IMHO but it'll be a source breaking change for users of setObjectMapper (Play Framework?)
  • serialize method for JsNumber: with Jackson 3, the actual implementation we get for JsonGenerator is a TreeBuildingGenerator that does not support writerNumber(String) (it used to support it with a wrong implementation, see also some context in TreeBuildingGenerator#writeNumber(String) writes Number as String FasterXML/jackson-databind#5528). Hence keeping a BigDecimal to use writeNumber(BigDecimal).
    • consequence: if shouldWritePlain is true, there's an extra BigDecimal allocation compared to before.
    • I also removed the TokenBuffer branch as I didn't see any reason to handle it specifically anymore
• JsonSpec: changed max depth as per Jackson change (1000 -> 500)
• 3 modules are now included by default in Jackson: ParameterNamesModule, Jdk8Module, JavaTimeModule, hence we no longer need to enable them explicitly (we couldn't anyway)

Remaining work

• Open issue and PR in play-framework to adapt the usage of setObjectMapper

References

• https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md

[pjfanning]

@gaeljw @mkurz Jackson 2 is stable and still supported. I don't see much reason to move to Jackson 3 yet. It could take a while for it to become stable. In Pekko, I'm retaining Jackson 2 support while adding Jackson 3 support in Pekko 2 as an option.
I don't know what the intent is here but I think dropping Jackson 2 and moving to Jackson 3 has its risks and difficulties.

[gaeljw]

The intent is only to be "up to date". I'm a bit surprised when you say Jackson 3 might not be stable yet: it's the default in Spring Boot for a few weeks now, a couple of libraries I know have already switched to Jackson 3... Do you have something specific in mind or it's just the fact that it's a major version and takes time to get feedbacks and detect issues?

I don't think there's any major reason to upgrade as soon as possible but on the other hand I don't see a reason to wait. The next minor version of Play could be a good candidate for the upgrade, isn't it?

Especially, as Jackson 2 and 3 can live together in the same codebase, this doesn't force users to have all their dependencies aligned on Jackson 3.

FWIW, we've been using Jackson 3 + Jackson 2 (both present at runtime, Play using 2.x and other libraries using 3.x) at work in a few projects for a few weeks and didn't have any issue so far.

[pjfanning]

@mkurz @gaeljw Jackson 3 is now onto v3.2.1 and can be regarded as being as stable as Jackson 2 latest releases.
Pekko 2 has milestone releases that have pekko-serialization-jackson3 libs that provide Jackson3 based serde support - and it should be easy enough for playframework to use that and switch to Jackson 3 too.
Akka may not have anything for Jackson 3 though. So switching to Jackson 3 may cause issues for playframework versions that are based on Akka libs.
Jackson 2 is maintained so switching to Jackson 3 is not absolutely required but there is an argument to try to switch to latest Jackson release.

[gaeljw]

I can spend a bit of time to rebase the PR on top of the latest changes (both Play JSON & Jackson) so that the status is up to date, I believe a few things changed in the meantime.

[gaeljw]

PR updated, tests are working. I'm working on a PR for playframework as well.