Inconsistent serialization with @JsonUnwrapped annotation using shared vs. new ObjectMapper instances

[SandeepGaur2016]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

I am using Jackson version 2.16.1 and have encountered a peculiar behavior. According to the API documentation, it is recommended to use a common ObjectMapper instance. However, I observe different serialization results when using a shared instance versus a new instance. I have reproduced this issue with a simple example.

public class First {
  @JsonUnwrapped(prefix = "")
  final Thrid thrid = new Thrid();
}
public class Second {
  @JsonUnwrapped(prefix = "fromSecond")
  final Thrid thrid = new Thrid();
}
public class Thrid {
  @JsonUnwrapped(prefix = "fromThird")
  final Common common = new Common("1", "2");
}

@JsonInclude(JsonInclude.Include.NON_NULL)
public class Common {

  public String getA() {
    return a;
  }

  public String getB() {
    return b;
  }

  String a;
  String b;

  public Common() {

  }
  public Common(String a, String b) {
    this.a = a;
    this.b = b;
  }
}

public static void main(String[] args) throws JsonProcessingException {
    First first = new First();
    Second second = new Second();
    ObjectMapper objectMapper = new ObjectMapper();
    System.out.println(objectMapper.writeValueAsString(first));
    System.out.println(objectMapper.writeValueAsString(second));
    System.out.println(new ObjectMapper().writeValueAsString(second));
  }

Output--

{"fromThirda":"1","fromThirdb":"2"}
{"fromThirda":"1","fromThirdb":"2"}
{"fromSecondfromThirda":"1","fromSecondfromThirdb":"2"}`

The output of the last two lines should be the same, but this is not the case. It appears that the @JsonUnwrapped annotation’s previous value for the Third class is being cached somewhere.
public class First { @JsonUnwrapped(prefix = "") final Thrid thrid = new Thrid(); }

If I use a non-empty string instead of an empty one in the above class, the results are consistent. Can someone please help us with this?

Version Information

2.14.2, 2.16.1, 2.17.2

Reproduction

<-- Any of the following

1. Brief code sample/snippet: include here in preformatted/code section
2. Longer example stored somewhere else (diff repo, snippet), add a link
3. Textual explanation: include here
   -->

public class First {
  @JsonUnwrapped(prefix = "")
  final Thrid thrid = new Thrid();
}
public class Second {
  @JsonUnwrapped(prefix = "fromSecond")
  final Thrid thrid = new Thrid();
}
public class Thrid {
  @JsonUnwrapped(prefix = "fromThird")
  final Common common = new Common("1", "2");
}

@JsonInclude(JsonInclude.Include.NON_NULL)
public class Common {

  public String getA() {
    return a;
  }

  public String getB() {
    return b;
  }

  String a;
  String b;

  public Common() {

  }
  public Common(String a, String b) {
    this.a = a;
    this.b = b;
  }
}

public static void main(String[] args) throws JsonProcessingException {
    First first = new First();
    Second second = new Second();
    ObjectMapper objectMapper = new ObjectMapper();
    System.out.println(objectMapper.writeValueAsString(first));
    System.out.println(objectMapper.writeValueAsString(second));
    System.out.println(new ObjectMapper().writeValueAsString(second));
  }

Expected behavior

Object mapper shared object should behave same as new instance as there is no configuration involved

Additional context

No response

[JooHyukKim]

Right, seems like sort of caching is affecting this behavior.

As an immediate solution, how about serializing all instances in intended order as warm-up?

Also, try to look for pre-existing issue. I think I saw similar Github issue

[cowtowncoder]

Yes, this definitely looks like a bug, possibly related to caching of serializers (or resolution via ResolvableSerializer). There is at least one failing test (and issue) but the one I recall was failing in different way I think (StackOverflow maybe).

[SandeepGaur2016]

Hi @cowtowncoder @JooHyukKim , I have pushed a fix for it, can you please review,
#4722

Thanks,
Sandeep gaur

[cowtowncoder]

Actually, I'm pretty sure this is dup of #2461 so will close as such, keep earlier one. Fixed by same PR.