Anyone familiar with using the Kotlin Jackson modu...

# server

[Charlie]

Anyone familiar with using the Kotlin Jackson module to parse out a JSON object with nested objects? For the nested objects it seems to only work in cases where the JSON matches exactly (@JsonIgnoreProperties and configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) do not help, though it works with the top level object). The failure is MismatchedInputException: Cannot construct instance, which I guess makes sense due to data class constructors, but is there some way to make this more flexible? Only parse the fields I need, and not break if the API returns a subset of the fields, or a new field? I'm a Kotlin newbie so just trying to figure this out as I go and any help would be appreciated.

[addamsson]

Is there a paticular reason for using jackson instead of kotlinx.serialization or Gson?

[mp]

Jackson is fast and flexible? Anyway, see #jackson-kotlin

[mp]

Post examples of the json you’re working with and the class. I’m doing what you’re describing without issues.

[gildor]

Not sure that there is any Kotlin specific thing, described case is supported by Jackson and should work with Kotlin out of the box

[Dico]

I usually avoid adding the kotlin module

[Dico]

I also think Jackson is great, a bit heavy sometimes but modular and much more flexible than Gson.

[gildor]

Also Jackson is still the fastest

[addamsson]

I see.

[addamsson]

Although I had difficulties using #jackson-kotlin on a project which uses both Kotlin an Java

[addamsson]

Gson on the other hand worked like a charm even with Kotlin data classes

[dave]

@addamsson interesting - we've had the experience that GSON doesn't fail on missing non-nullable properties when deserialising. Does it definitely work for you?

[addamsson]

https://stackoverflow.com/questions/33435683/deserialize-with-gson-and-null-values

[dave]

@addamsson maybe I'm missing something on the config side, but here's a test case that definitely doesn't work properly:

data class Obj(val required: String)

fun main() {
    println(GsonBuilder().serializeNulls().create().fromJson("{}", Obj::class.java ))
}

[dave]

(In that I'm expecting it to throw an exception)

[addamsson]

the it?

[dave]

🙂

[dave]

maybe I'm just missing an option there

[Dico]

@dave Gson was designed for java, where all reference types are nullable. It uses java reflection for deserialization, most likely. Thus, it cant possibly know unless it were somehow updated with a kotlin extension of some kind.

[dave]

@Dico yeah - that's what I suspected (and is entirely reasonable). I was just curious at the statement that it worked with Kotlin. 🙂

[Dico]

The only way it could naturally throw the exception is if it used a setter generated by the kotlin compiler. That setter doesn't exist

[Dico]

Fair enough. I would say it works reasonably well though.

[dave]

TBH, for us this problem makes GSON pretty much unusable for kotlin projects, especially since Jackson and Moshi both do support blowing up when fields are missing.

[dave]

but YMMV. 🙂

[Dico]

What about kotlinx-serialization?

[dave]

I'm not adverse to creating an http4k module for kotlinx.serialization, but not sure what features it would give at this present time over Jackson (at least for JSON and on the JVM).

[addamsson]

i'm just speaking from my experience

[addamsson]

I always ended up using gson instead of jackson

[addamsson]

because of the ease of use

[addamsson]

@dave there is one thing you can do with kotlinx.serialization which you can't do with anything else:
if you have a list of kotlin objects which have the same supertype they will be serialized using type information

[addamsson]

so by deserializing them you'll get back the concrete objects

[addamsson]

for example

[addamsson]

serializing a Foo and a Bar object which both have the same supertype Wom you'll get something like this:

[addamsson]

[
  ["com.example.Foo", { ... }],
  ["com.example.Bar", { ... }]
]

[addamsson]

i was not able to achieve this with jackson nor gson

[addamsson]

without custom serializers and such

[dave]

@addamsson fair enough. It's all to do with usage of course. 🙃 For us it's pretty much always deserialisation of Json to data classes. Since our API is a wrapper around the JSON libs, it's easier to use the one that supports the type system.

[addamsson]

sounds plausible

[addamsson]

i'm not sure about the future of kotlinx.serialization

[addamsson]

i really hope that they'll create something like protobuf

[addamsson]

they already have some annotations to support versioning, but it is far from complete

[addamsson]

full disclosure: I'm not using http4k for json serialization though

[addamsson]

I only have some mock servers written using it for running tests so I'm not the target audience

[addamsson]

btw I chose #http4k because it was the simplest thing I was able to dig up so kudos

[addamsson]

one more thing

[addamsson]

this might not be relevant in your case

[addamsson]

but kotlinx.serialization supports both Kotlin/JVM and Kotlin/JS

[addamsson]

I'm using it on both sides of the wire

[dave]

Yeah - i can see that would be attractive, although I might be worried about to much coupling between front and back end. IMHO, the multiplatform story is going to be quite a long game.

[dave]

And the gradle plugin stuff looks a bit scary...

[dave]

🙃

[addamsson]

tell me about it.......

[addamsson]

😄

[Dico]

the worst thing about multiplatform atm is gradle problems imo

[addamsson]

I agree.