ObjectMapper convertValue does not check if the value is already of target type

[lorenzbaier]

Why does objectMapper.convertValue not check if the object already has the desired target type and then return the object immediatly.

jackson-databind/src/main/java/com/fasterxml/jackson/databind/ObjectMapper.java

Line 4602 in 5e0deda

// inlined 'writeValue' with minor changes:

When converting a class which has a recursive getter of some form, I expect to get the object back immediatly if it has the correct type to begin with.

@Test
  void testConvertRecursive() {
    var convertedTp = new ObjectMapper().convertValue(new Recursive(), Recursive.class);
    assertNotNull(convertedTp);
  }

  public record Recursive(String name) {
    Recursive() {
      this("test");
    }

    public Recursive getSelf() {
      return new Recursive();
    }
  }

Instead I get: Infinite recursion (StackOverflowError) (through reference chain:....

[cowtowncoder]

Have a look at method definition (

jackson-databind/src/main/java/com/fasterxml/jackson/databind/ObjectMapper.java

Line 4541 in 5e0deda

* Note that behavior changed slightly between Jackson 2.9 and 2.10 so that

); there's some notes on why short-cut is not taken -- this used to be the behavior, but it is problematic for true conversion case where behavior between "proper" conversion (serialize-then-deserialize) and "fake" one (omit doing anything if type is already expected).

Issue for change in 2.10 was this:

#2220

[lorenzbaier]

Oh sry I didn't see that but thanks for pointing that out.

However I am wondering what is really meant by "let caller handle optimizations if ones are desired" (from #2220)?
How would you intercept the conversion of certain objects?

[yawkat]

Instead of mapper.convertValue(x, T.class), callers can just do if (!(x instanceof T)) mapper.convertValue(x, T.class).

[lorenzbaier]

sure the "first" level is not a problem, but what if the object is deeper down in the hierarchy?

[yawkat]

I don't think it's feasible at a deeper level. convertValue works by serializing and then deserializing. During serialization, the serializer has no knowledge of what type a particular property will eventually be deserialized to. So I don't see a generic approach happening.

If you have some contextual information you could eg create a serializer that uses writeEmbeddedObject instead of actually serializing a particular type.

[lorenzbaier]

Okay thanks for the info, I will look into a more specific solution that fits my use case.