Add support for Ahead-of-Time (AOT) compilation

[raderio]

Will be great if Retrofit will generate interfaces implementation at compile time. Something like Micronaut does.

https://github.com/micronaut-projects/micronaut-core Micronaut uses Ahead of Time (AOT) compilation to pre-compute your applications requirements at compile time. The result of this is significantly lower memory requirements, faster startup time, and reflection free framework infrastructure.

This will also make possible to better integration with GraalVM.

[raderio]

Another great example is Micronaut Data.icronaut Data is a database access toolkit that uses Ahead of Time (AoT) compilation to pre-compute queries for repository interfaces that are then executed by a thin, lightweight runtime layer. https://github.com/micronaut-projects/micronaut-data https://micronaut-projects.github.io/micronaut-data/latest/guide/

Or it is even possible to generate implementation classes like https://github.com/square/wire and https://www.jooq.org/doc/3.0/manual/code-generation/

[JakeWharton]

We have no plans for this.

Retrofit is too dynamic to adequately support this use case. It was investigated 5 or 6 years ago in the Retrofit 1 days and deemed infeasible, and 2 is even more dynamic than 1.

Moreover, there's little to gain by doing this. The cost of reflection (which is only done once and parsed into a model that can be cached) compared to the cost of the actual HTTP request is a difference of several orders of magnitude.

It may be worth revisiting this in a world where Kotlin's plugin infrastructure is stable since that would allow both AOT and multiplatform, but that's at least one or two or more years away.

[raderio]

As far as I know classes/code generated in runtime is more slower then code generated in compile time

[JakeWharton]

Speed of the Java Proxy not a factor here since the cost is dominated by I/O by many orders of magnitude.

[joimxjtuse]

@JakeWharton ，I can understand switch to AOT has little necessity, but could you show me some example for "Retrofit is too dynamic to adequately support this use case.", what “dynamic” may block AOT ？ i can not understand this. thks~.

[JakeWharton]

Any use of Converter.Factory or CallAdapter.Factory really. If you're doing AOT you'd want these to be resolved at compile time, otherwise you're still doing quite a bit of reflection at runtime. Not to mention there are no supported APIs for complex type literals (at least not in Java) so Retrofit would have to provide them to the generated code.

[joimxjtuse]

perfect, i know , very thks～

[joerg-wille]

Too bad that I have not read this thread before. I have been trying to compile a swagger/openapi generated client which uses RxJava with GraalVM SubstrateVM. At first I did not even know that swagger also added dependency for retrofit2. Know I at least understand why this attempt failed. Retrofit does not work with AOT.

Too bad that swagger-codegen and openapi-generator have no setting for creating RxJava client depended on another HTTP client, since my goal is use RxJava. I am also targeting Android with my application but using OpenJDK11 and JavaFX using SubstrateVM, therefore I am not directly tied to Android compatibility.

[CoderYellow]

qurakus,mcronaut http client has supported graalvm, any plan on this?