Is it true that ``call.receive`` doesn't work with generics because of erasure? I have trouble with...

# ktor

[cvmocanu]

Is it true that ``call.receive`` doesn't work with generics because of erasure?

I have trouble with this:

call.receive<List<Variable>>

It looks like the JacksonConverter ends up doing something like ``objectmapper.readValue(reader, List::class.java)``, which will obviously won't work.

It my suspicions are true, this is a big design issue in the Ktor API.
Jackson accepts a ``TypeReference`` instead of a ``Class`` precisely to suport this use case.

I guess my question is what are my options?
- writing my own converter is impossible, since I can't pass a TypeReference to call.receive
- changing the REST API is unacceptable

Is reading the request body as String and using Jackson manually my only option?

[orangy]

I think we did something with that, @e5l? Or was it only on http client side?

[Nikky]

i knot the clientside can do post just fine, and i had issues with call.receive until i switched from List to Array using jackson in ktor-server (usecase was testing the client json features)

[e5l]

The server doesn't use typeInfo because of performance reason. We consider introducing the separate way to use it in the server.

[cvmocanu]

thanks

So I have to deserialize the body myself.

Does anyone know how I can obtain a request InputStream?

[e5l]

http://ktor.io/servers/calls/requests.html#receiving

[cvmocanu]

thanks a lot

[cvmocanu]

for the record (in case other need this), this is what I did:

val variables: List<Variable> = restApiObjectMapper.readValue(call.receiveStream(), LIST_OF_VARIABLES)

,

where

companion object {
    private val LIST_OF_VARIABLES = object : TypeReference<List<Variable>>(){}
}

[rharter]

Was discussing how to handle this last week for Moshi. Originally thought a content converter could add an extension function to call to handle this, like call.receive(listTypeInfo), but that would preclude the whole "content negotiation" idea (using the content type header to determine how to deserialize, this would restrict to only JSON, which might be okay in your instance)

[cvmocanu]

where would I store ``listTypeInfo`` so I can retrieve it in the converter?

[rharter]

That's where this breaks the flow. This would have been something that the converted would add to the call class, which would basically do the deserialization from the call manually like you did, given the typeInfo passed in. The problem here is that, while it looks like it's following normal ContentNegotiation procedure, it would actually bypass the negotiation part of it, and only do JSON conversion, as opposed to taking into account the Accepts header of the client request.

[rharter]

That's why I didn't move forward with this approach.

[Marc Knaup]

What is the performance issue with typeInfo?

I use a similar approach but try to cache instances based on `ParametrizedType`: https://github.com/fluidsonic/fluid-json/blob/c3bda8e59adb6dbb5cf3fe4f8edace9f422c033a/Sources/JSONCodableType.kt#L75

I'd love to see better generics support for .receive()!

[e5l]

Each typeInfo callSite generates new classfile

[Marc Knaup]

How does that affect performance? Doesn't it affect just the memory footprint?