This message was deleted.

# jackson-kotlin

[Slackbot]

This message was deleted.

[Dan]

Trying this:

data class TransferQuoteRequest(
    @JsonProperty("sendCcy")
    val sendCcy: Currency,
    val receiveCcy: Currency,
    val amount: BigDecimal,

    @JsonProperty("isSendCcy")
    val isSendCcy: Boolean
)

Gives:

Conflicting/ambiguous property name definitions (implicit name 'isSendCcy'): found multiple explicit names: [sendCcy, isSendCcy], but also implicit accessor:re

[dinomite]

Terminology note: serialize an object into JSON, deserialize from JSON into an object

[dinomite]

This has to do with the unfortunateness of the Java Beans specification around boolean field naming

[Dan]

Interesting. Is it then best to stay away from fields beginning with is?

[dinomite]

That, combined with the fact that val constructor parameters in Kotlin are really expanded to multiple things (a getter, setter, constuctor param, and field) makes for a very confusing situation

[dinomite]

Yes, avoiding is is preferable, but in your case I don’t think that would help

[dinomite]

You could make isSendCcy be isSendCcyPresent

[Dan]

Well changing the field name to something else (amountInSendCcy ) worked fine

[dinomite]

Or applying use site targets might help, too (e.g. @get:JsonProperty("…")) https://kotlinlang.org/docs/annotations.html#annotation-use-site-targets

[dinomite]

Any reason for abbreviating currency?

[Dan]

Great. Thanks Drew, that’s really helpful

[Dan]

Nope, just abbreviating. Ccy is a common abbreviation for currency

[dinomite]

Fair enough; I often see abbreviations overused in an attempt to save bits on the wire when relying on compression (which is almost certainly already, transparently in place0 is a far better solution

[dinomite]

Not to mention the fact that if bits matter then protobuf is the real answer

[Dan]

Ah I see-- Yeah, we’re not there yet 🙂