Generated Android client has high number of referenced methods

[who]

In an Android app, there is a limit on the number of methods you can have. This limit is ~65k.

Because of the dependencies that it imports, the android-java client generated by swagger-codegen has a significantly high number of methods referenced. We should see if this can be reduced.

Below is an example. Note: the example relies on https://gist.github.com/who/cdb37baffa7f64d27180

me@box:/tmp/tmp.wMZIQvX55e$ git clone https://github.com/swagger-api/swagger-codegen.git
...
me@box:/tmp/tmp.wMZIQvX55e$ cd swagger-codegen/samples/client/petstore/android-java
me@box:/tmp/tmp.wMZIQvX55e$ mvn clean install
...
me@box:/tmp/tmp.wMZIQvX55e/swagger-codegen/samples/client/petstore/android-java$ for jar in ./target/lib/*.jar; do dexcount $jar; done | paste -s -d+ | bc
16881                         
me@box:/tmp/tmp.wMZIQvX55e/swagger-codegen/samples/client/petstore/android-java$ for jar in ./target/*.jar; do dexcount $jar; done | paste -s -d+ | bc
342

[fehguy]

The main culprits will be JSON and HTTP support. using gson should help considerably as we don't need all of Jackson's fancy methods for android.

[who]

@fehguy Yes, swapping for gson would be good start. The Jackson libs alone contribute 7-8k to the limit.

[who]

@fehguy

I have been looking into this. Here is what I propose: We should change the swagger-codegen templates to, wherever possible, use libraries contained within the Android API bucket. If these libraries are used, they do not count against the method limit.

[fehguy]

@who that's the right move.

[0legg]

@fehguy @who Another reason to change android template is deprecation of built-in Apache HTTP client. I think implementing #465 will fix this issue as well as #686. I've got WIP candidate for this fix, but I'm not sure that all stuff will work as well as it supposed to be.

[who]

@fehguy @0legg

I found that using the basic Android API to parse a string of JSON into a pojo instance is tough and ugly. So, the JSON stack is still one area that probably would be best left up to other libs. It makes more sense to use gson over jackson for this, as we are currently only using a small fraction of jackson's capabilities, and gson is only 1200 methods compared to jackson's ~7500.

[fehguy]

@who I get it. The code generator, though doesn't have feelings so we can make it do a bit more work than we'd like to write manually, if it makes more efficient code. I'll look in a while to see if we can put some generalizations on top of the android generator.

[webron]

Out of curiosity, won't jackson-jr alleviate the issue with the methods?

[who]

@webron I just cloned the jackson-jr repo, compiled it, and counted the methods in the resulting jar.

The method count is 2852, still higher than gson's 1233.

[webron]

Cool, thanks for checking. The reason I asked is from my limited experience (including in Android), Jackson tends to perform significantly better than Gson which is why many developers opt to use it. Eventually, people can customize the codegen to suit their needs.

I definitely don't have a preference for one over the other (in this context).

[0legg]

@webron Actually, Jackson performs significally better when it's used in the stream mode, as pull-parser. In mapping mode it's not overperforming Gson so much.

[webron]

@0legg - guess we had a different experience ;)