You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming we ended up with strange modelling like this one Model1<Model2<Model3>>, present day version of JsonXConverterFactory, namely responseBodyConverter, will crash here type.actualTypeArguments.first() as Class<*> (because first() is also ParameterizedType, which, can go on and on)
Question: is it bug or feature? :) Clearly, this can be bypassed and surely this kind of modelling is bad in the first place, so I'm just curious about "creators intent" here.
The text was updated successfully, but these errors were encountered:
@oradkovsky this is a good point! To be honest, we didn't intend to support nested generics, but we will definitely consider it for the future updates.
Even though modelling a n-depth generic class is probably a bad idea, this could be solved in the library by using some recursive approach.
I will make sure to add this to our to-do list for the next release. Thank you very much for your feedback!
hello! Please consider this as question.
Assuming we ended up with strange modelling like this one
Model1<Model2<Model3>>
, present day version of JsonXConverterFactory, namely responseBodyConverter, will crash heretype.actualTypeArguments.first() as Class<*>
(because first() is also ParameterizedType, which, can go on and on)Question: is it bug or feature? :) Clearly, this can be bypassed and surely this kind of modelling is bad in the first place, so I'm just curious about "creators intent" here.
The text was updated successfully, but these errors were encountered: