@JsonUnwrapped bombs out in 2.9.x

This test case passes with 2.8.9 but fails with 2.9.2:

class JacksonTest {
  data class ParentClass(
      @field:JsonUnwrapped val child: ChildClass? = null,
      val otherValue: String? = null,
      @field:JsonIgnore val internalData: String? = null)

  data class ChildClass(
      val value1: String? = null,
      val value2: String? = null)

  @Test
  fun tryDeserializing() {
    val mapper = ObjectMapper().registerModule(KotlinModule())

    val json = """{"value1": "something", "otherValue": "something else"}"""
    val result = mapper.readValue(json, ParentClass::class.java)

    assertEquals("something", result?.child?.value1)
    assertNull(result?.child?.value2)
    assertEquals("something else", result?.otherValue)
  }
}

Unfortunately this has us in a bit of a bind, because 2.8.9 is not compatible with Kotlin 1.2 which we’d like to move to.

[sgrimm-sg]

Sure, that’s possible. In any case, seems like this is not something that can easily be addressed, and certainly not in the Kotlin module, so I’ll close this issue. Thanks for taking a look at it.

I should add that one more workaround (which we may implement) occurred to me after filing this issue: add a secondary constructor, annotated @JsonCreator, that has arguments for all the child object fields, and then explicitly construct the child object in the constructor. Not totally ideal, but it’d be compatible with 2.9 and wouldn’t require making structural changes to the classes.

[cowtowncoder]

@sgrimm-sg I agree with the likely accidental (or, fortunate in some way) alignment of events. Often nastiest problems are ones that can work in certain sequencing (in this case, when properties can be decoded in “optimal” order, without buffering) but not with others. Some of the background may be found at:

https://github.com/FasterXML/jackson-databind/issues/265

which is the issue that tracks explicit checking to prevent problematic usage.

One last thing that may be of interest is to notice that JVM’s final limitation does not actually limit all access via Reflection: fields may be set for a brief period of time after allocation of actual Object frame, presumably to allow JDK serialization to assign values. I have not seen formal specification for exact limits, I just know that final fields may be overridden via Reflection, but not for indefinite time after instance creation. Not sure that is relevant here at all, but Jackson does have MapperFeature.ALLOW_FINAL_FIELDS_AS_MUTATORS for this … aspect. And it is enabled for backwards compatibility. So perhaps unwrapped value(s) would be assigned via final fields here, with 2.8?