Summary of Suggested Changes

[nrayburn-tech]

Patch

1. ~Bump dependency versions to latest. https://github.com/OpenAPITools/jackson-databind-nullable/issues/60 https://github.com/OpenAPITools/jackson-databind-nullable/pull/64 https://github.com/OpenAPITools/jackson-databind-nullable/pull/59 https://github.com/OpenAPITools/jackson-databind-nullable/pull/52~
2. ~Setup Renovate or something similar for long term maintenance. https://github.com/OpenAPITools/jackson-databind-nullable/issues/71#issuecomment-3270770186~
3. ~Update GitHub Actions to use commit sha instead of version numbers (security improvement of workflows).~
4. Test on Java 8 and latest Java version to ensure compatibility as versions are released.

Minor

1. Add methods to JsonNullable to make use with streaming APIs easier. https://github.com/OpenAPITools/jackson-databind-nullable/issues/65 https://github.com/OpenAPITools/jackson-databind-nullable/pull/68 https://github.com/OpenAPITools/jackson-databind-nullable/pull/56 https://github.com/OpenAPITools/jackson-databind-nullable/issues/7
2. ~Improve module-info. (Could be major if the module name needs to change, but I think that could be separate from other module-info improvements.) https://github.com/OpenAPITools/jackson-databind-nullable/pull/62~

Major

1. Stop extending jackson-base and use jackson-bom dependency management instead. jackson-base is only meant for projects owned by the Jackson team. This could be done as a minor, but there's a few different parts that could be seen as breaking so major is safer. https://github.com/OpenAPITools/jackson-databind-nullable/pull/98
2. Jackson 3 compat. Unsure if there's a trivial way to support Jackson 2 and 3 at the same time, probably not. Would need either 2 concurrent versions in this repo, or just move on to Jackson 3. Given the infrequency of updates in this repo as-is, moving on to Jackson 3 may not be too problematic. https://github.com/OpenAPITools/jackson-databind-nullable/pull/73
3. Review the requirement for a serialization inclusion of NON_NULL. Requiring users to configure this can be confusing. It would be better to automatically do this for properties that are JsonNullable<T>. Unsure if this is possible. https://github.com/OpenAPITools/jackson-databind-nullable/issues/55
4. Review and possibly change the behavior for deserializing empty strings. It's a bit odd that empty strings are treated as undefined when an empty string is a completely valid value. https://github.com/OpenAPITools/jackson-databind-nullable/issues/46 https://github.com/OpenAPITools/jackson-databind-nullable/issues/26

[nrayburn-tech]

Setup info for Renovate https://docs.renovatebot.com/getting-started/installing-onboarding/#hosted-githubcom-app.

Created a config here that I think should be good to use https://github.com/nrayburn-tech/jackson-databind-nullable/blob/renovate-config/.github/renovate.json.

[nrayburn-tech]

@Til7701 @wing328 we should probably finish the two enhancement PRs linked below, but I think after that we can create a new release. Is there anything else either of you think needs to be in the next release?

https://github.com/OpenAPITools/jackson-databind-nullable/pull/62 https://github.com/OpenAPITools/jackson-databind-nullable/pull/68

[nrayburn-tech]

@wing328 would it be possible to create a release within the next few weeks? There’s been a few enhancements added (specifically the streaming methods) that would be nice to have released.

[wing328]

i'll try to cut a release this weekend

have a nice weekend

[wing328]

done: https://central.sonatype.com/artifact/org.openapitools/jackson-databind-nullable/0.2.8

please check

[nrayburn-tech]

I should be able to test pulling it into a project later today.

The release notes have a typo on the version number in the title. 2.0.8 instead of 0.2.8. https://github.com/OpenAPITools/jackson-databind-nullable/releases/tag/v0.2.8.

[wing328]

thanks for pointing it out.

fixed the typo

[nrayburn-tech]

Tested it with two projects locally and didn’t have any issues.

[nrayburn-tech]

@wing328 do you want to continue supporting a 0.2.x version that is compatible with Jackson 2 or do you want to move on to only supporting Jackson 3 in either a 0.3.x/1.x.x version?

I think if keeping a 0.2.x version is desired, it probably makes sense to create a new branch for it and let the master branch start accepting PRs for 0.3.x/1.x.x. The only additional change would be to update the release GitHub action to also do releases on merges into the 0.2.x branch.

[wing328]

do you want to move on to only supporting Jackson 3 in either a 0.3.x/1.x.x version?

I don't think that's a good idea at this stage since Jackson 3 GA release was out on Oct 3, 2025

Did your project(s) already migrate to Jackson 3.x?

My current take is to create a 3.x branch (or 0.3.x branch) to support Jackson 3.x and let community (those who needs Jackson 3.x) to drive it while this project primary focus should still be Jackson 2.x before Jackson 3.x gains more adoption from the community.

[nrayburn-tech]

My projects are Spring based, so they won’t adopt Jackson 3 until the Spring 7 release in the next month or so. (And this is the absolute earliest they could migrate, not necessarily when it would happen.)

The only reason for dropping Jackson 2 is because of how infrequent this project is changed/released.

I agree that supporting both is the better approach, but I wanted to at least ask the question.

When you get a chance, can you create the 0.3.x branch?

[wing328]

just created https://github.com/OpenAPITools/jackson-databind-nullable/tree/0.3.x

[nrayburn-tech]

Thanks, I'll get some PRs put up for it soon.