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
Clone of #4758. Many projects in the Java ecosystem have already migrated (or are migrating) to Jackson 3. As a result, consumers of this library might need to support both Jackson 2 and Jackson 3 dependency trees simultaneously, which complicates dependency management, mainly when updating for security issues.
It would be valuable to plan a migration to Jackson 3 and release it as part of the next major version.
Considerations
This change would require a major version bump due to inevitable breaking changes in the public API (the IntOrString class) and dependency requirements.
Jackson 3.x requires Java 17+, which should be clearly communicated as a runtime baseline change.
Alternatives
Drop explicit support for Jackson in the core library and let downstream projects register the serializer.
This would require this to be added to the upstream generator, and also for us to move the minimum java from Java 11 to java 17 which I don't think we're planning currently.
If you wanted to make the serializer pluggable, again, that would be something that needs to be done in the upstream code generator and do it in such a way that it doesn't harm the usability of this library.
Activity
brendandburns commentedon Oct 8, 2026
This would require this to be added to the upstream generator, and also for us to move the minimum java from Java 11 to java 17 which I don't think we're planning currently.
If you wanted to make the serializer pluggable, again, that would be something that needs to be done in the upstream code generator and do it in such a way that it doesn't harm the usability of this library.