Nullable unsigned numbers do not serialize correctly

[bholzman]

Using Kotin 1.3.0-rc-190 and jackson 2.9.7, nullable unsigned integers serialize as an empty object, even when they have a value.

Given:

data class Foo(val signed: Int, val unsigned: UInt, val nullableSigned: Int?, val nullableUnsigned: UInt?) {
    private val mapper = jacksonObjectMapper()

    fun asJson() : String{
        return mapper.writeValueAsString(this)
    }
}

Then this:

println(Foo(23, 23U, 23, 23U).asJson())

outputs:

{"signed":23,"unsigned":23,"nullableSigned":23,"nullableUnsigned":{}}

[TjeuKayim]

Unsigned integers are implemented as inline classes, so related to #199.

[TjeuKayim]

@ExperimentalUnsignedTypes
@Test
fun unsigned() {
    data class Foo(val signed: Byte, val unsigned: UByte)
    val obj = Foo(25, 250U)
    val json = mapper.writeValueAsString(obj)
    assertEquals("""{"signed":25,"unsigned":250}""", json)
}

Throws java.lang.AssertionError: Expected <{"signed":25,"unsigned":250}>, actual <{"signed":25,"unsigned":-6}>.

More unit-tests I coded: https://github.com/TjeuKayim/jackson-module-kotlin/blob/36eca83af1e73aa67b54c5f7374da51287ae96f4/src/test/kotlin/com/fasterxml/jackson/module/kotlin/test/Github205.kt#L184-L228

[apatrida]

thanks @TjeuKayim

[efenderbosch]

Just encountered this today, using Kotlin 1.4 and Jackson 2.12.1.

Serializers such as this solve the problem. Worth a PR to add a serializer for each of the unsigned numbers?

object UIntSerializer: StdSerializer<UInt>(UInt::class.java) {
    override fun serialize(value: UInt, gen: JsonGenerator, provider: SerializerProvider) {
        gen.writeNumber(value.toLong())
    }
}

[cowtowncoder]

Sounds like something for which PR would be good. Presumably also needs matching deserializers and ideally key (de)serializers (if used as Map keys)?

[efenderbosch]

Since the unsigned number types are all inline, deserializers don't help much. Every class using these types will need a custom Deserializer/@JsonCreator/ctor to take in the standard Java type that the inline class is wrapping. Then check bounds and wrap, then pass to regular ctor.

The deserializers will really only help if someone is serializing/deserializing one of these types standalone, not as an attribute of another object.

[cowtowncoder]

Ah. Thank you for clarifcation, that makes sense (and was implied by reference to inlined classes; it's just my unfamiliarity with Kotlin implementation details that it only now makes sense).

[efenderbosch]

Until project Valhalla delivers inline classes to Java, we are pretty much out of luck for deserializing Kotlin inline classes w/o all sorts of ceremony.

[cowtowncoder]

Yeah that's not going to happen any time soon. Might be something to document, then, as a limitation.
Assuming this is non-obvious limitation which it seems like.

[efenderbosch]

branch from 2.12 or 2.13 @cowtowncoder ?

edit: I ended up going off of 2.13 because 2.12 failed to build from a clean checkout

[cowtowncoder]

@efenderbosch Ah sorry missed this one: 2.12 would be slightly better but it can probably be cherry-picked.

[cowtowncoder]

Ok I see; not sure why that test failed, added a note on relevant issue.

2.13 may make sense, all around: I'll let @dinomite chime in on that.

[dinomite]

2.13 is fine, I'll be able to cherry pick it onto 2.12. Now to figure out what's wrong with 2.12…