HHH-19890 Add Jackson 3 FormatMapper support

[nrayburn-tech]

This adds Jackson 3 support alongside the existing Jackson 2 support.

1. If Jackson 3 is available, it is the preferred option with the automatic detection. This might be undesirable, so it may be worth changing before removing.
2. OSON doesn't support Jackson 3 right now.
3. There is duplicate code between the Jackson 2 and Jackson 3 support. There could likely be some refactoring done to reduce this if that's desired (either in this PR or a separate one).
4. I'm not sure if there are missing tests for this.
5. I didn't test this in a separate project or anything, just ./gradlew clean build.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19890

[nrayburn-tech]

Not sure if the previous author's need to be retained. This file was copied from the existing one that they were on. (I also don't need my name in here either unless it's the project standard, just tried to match what I copied from.)

[cigaly]

You should take care of backward compatibility. Jackson 3 does not have JSR 310 module since it is handling java.time.* classes, but in a different way than Jackson 2 module.

Here is one example that is showing the problem

JsonJavaTimeMappingTests.java

[nrayburn-tech]

Thanks @cigaly, I added the tests and updated the implementation to pass.

Are you suggesting that the new Jackson 3 support should match the existing Jackson 2 support as closely as possible or are you only concerned about the java.time.* handling?

Jackson 3 changed default options for some features, so the new code here would just need to configure those back to the Jackson 2 values. I don't think there's a problem with this, but I wanted to check before I make that change.

[cigaly]

Main point is that one should be careful with backward compatibility. If I have project that was using Hibernate + Jackson 2, then I would expect that it will work with Jackson 3 as well without some major code changes. I am not 100% sure how many incompatibilities are introduced when switching from Jackson 2 to 3, java.time is one that I've met while upgrading my project to Spring 7. It is, however, possible that there some other unknown to me.

One good thing with java.time is that Jackson 3 would likely be able to read/deserialize objects written/serialized with Jackson 2. I've run some quick tests where Jackson 2 has been used to serialize and Jackson 3 to deserialize. This is (most likely) working. If Jackson 2 can deserialize what has been serialized with Jackson 3, then my comment about backward compatibility can safely be ignored.

[nrayburn-tech]

I think it’s a reasonable concern. Even if Jackson can serialize/deserialize the data if it isn’t the same format, there could still be other impact if the data being stored in the database is changed.

1. This is being added as part of the automatic detection. Maybe it should be opt-in only instead.
2. I believe this feature is still in Incubating, so compatibility changes like this should be ok but probably need to be well documented. (I got the incubating status from the json_format_mapper, so I could be misinterpreting the incubating status for this feature.)
3. Jackson changed the defaults for a reason, so configuring back to the Jackson 2 values here feels odd.

Not sure if any of that changes your opinion on how much we configure the Jackson 3 support to align with the existing Jackson 2 support.

I can review the relevant Jackson features, but I think it will be 10+ that need to be explicitly configured to old defaults to be safe.

[nrayburn-tech]

Jackson offers a method that configures the mapper to use the Jackson 2 settings. I’ll adjust the PR to use that. This will resolve most of the concerns, but it’s probably still worth considering if Jackson 3 is part of the automatic detection or not.

[nrayburn-tech]

Updated the code to use the Jackson methods to use the Jackson 2 defaults. I found a few discrepancies and opened PRs against Jackson to resolve those.
FasterXML/jackson-databind#5456
FasterXML/jackson-core#1514

[beikov]

Looks like MySQL adds some spaces to the JSON that we have to account for.

Suggested change

	"{\"instant\": 1764576582.000000000, \"duration\": 11640.000000000, \"localDate\": [2025, 12, 1], \"localTime\": [9, 9, 42], \"localDateTime\": [2025, 12, 1, 9, 9, 42]}";
	"{\"instant\": 1764576582.000000000, \"duration\": 11640.000000000, \"localDate\": [2025, 12, 1], \"localTime\": [9, 9, 42], \"localDateTime\": [2025, 12, 1, 9, 9, 42]}";
	String alternativeMySQLJson =
	"{\"instant\": 1764576582.000000000, \"localDateTime\": [2025, 12, 1, 9, 9, 42], \"localDate\": [2025, 12, 1], \"localTime\": [9, 9, 42], \"duration\": 11640.000000000}";

[nrayburn-tech]

Is there an easy way for me to test this locally?

I updated the test with a MySQL version and a MariaDB version based on what I'm seeing as failed in CI.

[beikov]

Ughh, this start to get ugly. Can you try parsing the JSON with the format mapper to e.g. a Map and do the comparison that way?

See the README which explains how to start and run against databases locally ;)