Unable to deserialize collections

[henryju]

Any API returning a collection fail to be deserialized.

Can not deserialize instance of java.util.ArrayList out of START_OBJECT token
at [Source: org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream@7586beff; line: 1, column: 1]

This is because ApiResourceEntityProvider will unwrap collections when the target object is of type java.util.List, but generated code make use of ArrayList. And List != ArrayList.

I suggest to fix the generator to replace ArrayList by List (this is a good practice in Java to not expose implementation in APIs).

[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