Unable to deserialize collections

[microsoft]

Unable to deserialize collections

[AlexRukhlin]

Hi,

(Just a side question: Which version of Java do you use?)

As a short workaround you could modify the line in ApiResourceEntityProvider to support both List and ArrayList.

We'll be glad to receive a Pull Request with your contribution.

Thanks,
Alex

[henryju]

I'm using Java 8. I can submit a PR, but I'm still thinking that exposing java.util.List instead of ArrayList would be cleaner. And since this is generated code, I'm not sure I should create a PR to change it. Or is the code of the generator available somewhere?

[AlexRukhlin]

I agree with you that exposing java.util.List instead of ArrayList would be cleaner. Just in the current implementation, we can not use interfaces in places where deserialization is needed, e.g. in method return types.

You shouldn't change generated classes. You might see two types of sources - ones are generated the others are manually created. ApiResourceEntityProvider is a manually created class.

[henryju]

During my tests, I have changed for example the return type of GitHttpClientBase.getPullRequestIterations() to java.util.List and it was working fine. Are we talking about the same thing?

[AlexRukhlin]

Yes, we do. You might see that in GitHttpClientBase.getPullRequestIterations() the type ArrayList<GitPullRequestIteration> is used two times - as the method's return type and as a part of the parameter in the super.sendRequest call specifying the deserialization target type, i.e. the response type. Sorry, in my previous comment, I used the same term "return type" for both. That was confusing. :-(

Manually, you've changed only the result type. Correct? As I said, in the current implementation of the REST Client Generator, we cannot do that. We're planing its improvement, but but do not have ETA yet.

That's why I've suggested the short workaround.

[henryju]

Manually, you've changed only the result type. Correct?

No, I changed both. I will prepare a P/R to show you