On Thu, May 2, 2019 at 8:11 PM Matt Sun <sjf.m...@gmail.com> wrote: > > Hi Jackson-users! > > We are looking to upgrading an old library that uses databind-2.6.6 to 2.9.8 > due to security vulnerability issues. Due to the nature of this old library, > we are trying to avoid making code changes if possible. Can anyone provide > some insight of whether the API of 2.6.6 and 2.9.8 are compatible or not? Is > there any potential code change required other than update the dependency?
Hi Matt! Typical application code should be fully binary and source compatible across 2.x versions, and no changes should be needed: Jackson attempts to follow Semantic Versioning for its API. This includes all public method calls, configuration settings, and especially functionality exposed by main abstractions (ObjectMapper / ObjectReader / ObjectWriter; JsonFactory / JsonParser / JsonGenerator; all various XxxFeature settings). But the caveat is that some of internal extension points are more aggressively deprecated over minor versions, and so there are cases where compatibility is guaranteed across adjacent minor versions in that methods may be deprecated in a minor version and in some cases removed in a later minor version. Difficulty comes in figuring out where the difference lies, of course; but as a general rule extension by subclassing is where most incompatibilities lie -- changes are typically ones where a new method with additional argument(s) is added first, old one deprecated (but passing a placeholder default value) and eventually removed when it is impractical to maintain. Since even internal interfaces use deprecation as a marker, I recommend upgrade by going from current version to newer one by first upgrading 2.6 -> 2.7, compiling, running tests and in particular observing any Deprecation warnings. If any are found, those are good indications that a change is needed eventually, and Javadocs for the version should indicate what a replacement method is. If all goes well this may not be much slower than going straight from 2.6 to 2.9. But if things go wrong it is probably faster to do it that way. Having said all of that, my understanding is that majority of users can upgrade with no code changes. At my current job (s/w-focused company with ~10,000 employees) I have migrated global default Jackson version first from 2.5 to 2.7 (last year) and 2.7 to 2.9 (1 month ago) with only limited compatibility challenges; and those challenges were mostly related to Guava version compatibility where Jackson Guava module brought newer version which caused issues in some cases for another 3rd party library. But others can share their experience. Finally, I think the most common behavioral difference that is visible and can potentially cause issues filtering: and especially definition of `@JsonInclude.Include.NON_DEFAULT` (and `NON_EMPTY`); and how it applies to values of `Map`s. Its definition has evolved in ways that has not been optimal, due to attempts to fix initial problems in 2.5. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
