On Fri, Jul 27, 2018 at 2:03 PM, <[email protected]> wrote: > I have a need in my program to convert custom typed JavaBean/POJO-type > objects into "untyped" equivalents. This means turning a top-level object > into a Map and recursively doing the same to all objects referenced by the > top-level object. > > Jackson's convertValue method has been a convenient way to do this: > > public Map<String, Object> beanToMap(Object bean) { > return jacksonMapper.convertValue(bean, Map.class); > } > > I'm now in the process of upgrading my Jackson dependency from 2.6.3 to > 2.9.6 and the behavior is a bit different now. convertValue has a short > circuit where it does nothing if it sees that the passed-in object is > already assignable from the target class. It looks like this was always the > intent, it's just that before the changes to the TypeFactory in this commit > an attempt to convert to Map would always miss the short circuit because Map > would be converted to a JavaType that had generic types on it. Now the type > erasure done in the TypeFactory allows the short circuit code to trigger. > > From Jackson's perspective this seems like a bug fix, but in my use case the > short circuit is a problem since sometimes the top-level bean is already a > Map but it has values in it that are still POJOs. My goal is for the entire > object graph represented by the passed-in bean to become untyped, but now > this only happens if the top-level object is a POJO too. > > I've worked around the problem by wrapping the Object parameter in another > bean that's definitely not a map, then pulling it out again after the > Jackson conversion. This dodges the short circuit and gets the method back > to working as I want. > > The comment for the ObjectMapper.convertValue method says this: > > * Note that it is possible that in some cases behavior does differ from > * full serialize-then-deserialize cycle: in most case differences are > * unintentional (that is, flaws to fix) and should be reported. > * It is not guaranteed, however, that the behavior is 100% the same: > * the goal is just to allow efficient value conversions for structurally > * compatible Objects, according to standard Jackson configuration. > > This is definitely a case where convertValue is acting differently than a > full serialize-then-deserialize cycle so my question is: Is this a flaw? I > can understand the desire to short circuit the type conversion but it does > seem suspect to base that decision on the top-level type when the > conversion, if it happens, will affect the entire object graph.
Ok, how about this: could you file an issue (if not already done: I am bit behind my emails) for specific problem you are having with 2.6 -> 2.9 upgrade. Second part, I think, is that there probably should be an alternative for something like "forced" conversion; there may or may not be an issue for that as well. Such method would be added in 2.10, and would never short-circuit but do write-to-buffer/read-back cycle. -+ 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 [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
