Why retrofit use reflection instead of APT to implementate the APIs ?

[Goooler]

Like the title, it's been an impenetrable question for me for a long time.

[pyricau]

A few reasons come to mind:

• At the time Retrofit was built internally at Square, annotation processors were still nascent and tooling wasn't great.
• The performance boost from generating code instead of java dynamic proxies is not really interesting since most of the time is spent waiting for the network to respond.

[JakeWharton]

I'm not sure either of those are strictly true.

I built an annotation processor-based Retrofit around the same time I built an annotation-processor based Otto around the same time I built Butter Knife in early 2013. The Otto one was thrown out because our event bus usage was minimal and did not foresee the widespread abuse of event buses that would soon follow. The Retrofit one was thrown out because it becomes way too hard to support all the dynamism that makes Retrofit powerful: different converters, different execution mechanisms (what would become adapters), and different HTTP clients (later to be removed). It also would have required exposing APIs to build Types at runtime which at the time we were not already shipping (but later would).

For reflection-based libraries like Moshi we say its steaming nature allows us to amortize the cost of reflection over the 10-100x slower network or disk-based I/O. But for Retrofit its own reflection happens synchronously on the calling thread (usually main) and on the first call the penalty is very observable. The whole motivation behind pursing an annotation processor-based implementation did not have anything to do with the speed of serializing or deserializing HTTP bodies, but instead to eliminate the reflection and parsing of the annotations and types on the service methods.

The only way to achieve #3181 is with code generation so looks like we'll be going back to figuring it out soon enough.