Cool - if this is indeed faster than Jackson (and GSON), I would recommend writing a Retrofit converter (<a href="https://github.com/square/retrofit/tree/master/retrofit-converters" rel="nofollow">https://github.com/square/retrofit/tree/master/retrofit-conv...</a>) so developers can just drop in ig-json-parser for use with Retrofit.
This looks cool, but I'm also interested in seeing if compared to GSON not just Jackson. Is the `JsonField` annotation mandatory? In most cases my variable names are the same as the field names in the JSON, which is why I love using GSON since it auto-picks up on that.<p>It looks kind of odd in your sample code too, it'd be nice if it could auto-try those fields, but I can see why that won't work if this is compile-time rather than at processing-time like GSON (it has no way of checking against the JSON to see if that assumption is true) -- maybe have `JsonType` take and optional parameter that enables "guess types" mode?
And look at how slow it still is. 40ms to parse json? I can do that around or under 1ms in iOS. When porting our app to android this was one of the biggest unexpected bottlenecks that really impacts performance. I don't know why android doesn't provide a native json implementation to reduce this barrier to entry.
I've added an issue to chidley to generate these classes, in addition to the Java/JAXB classes it produces now: <a href="https://github.com/gnewton/chidley/issues/4" rel="nofollow">https://github.com/gnewton/chidley/issues/4</a><p>(Of course only for json generation from XML)
How does this compare to loading up a String of json in an org.json.JSONObject and parsing it manually?<p>For some further abstraction/encapsulation, you can extend the JSONObject class and provide getters/settings for particular key/values.