Skip to content

[Kotlin][Client] Added new option to enable moshi code generator #4781

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 14, 2019

Conversation

AlexanderEggers
Copy link
Contributor

@AlexanderEggers AlexanderEggers commented Dec 13, 2019

Moshi introduced a new code generator that provides a better performance than the current used KotlinJsonAdapterFactory solution. To enable the generator, every data class needs to use the new annotation @JsonClass(generateAdapter = true).

Changes made with this PR:

  • Added new option to enable moshi codegen. Option available via moshiCodeGen.
  • Updated kotlin to 1.3.61.
  • Updated moshi related dependencies to 1.9.2.
  • Updated samples

PR checklist

  • Read the contribution guidelines.
  • If contributing template-only or documentation-only changes which will change sample output, build the project before.
  • Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
  • File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
  • Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@jimschubert (2017/09) ❤️, @dr4ke616 (2018/08) @karismann (2019/03) @Zomzog (2019/04) @andrewemery (2019/10) @4brunu (2019/11)

@4brunu
Copy link
Contributor

4brunu commented Dec 13, 2019

Is there any disadvantage in this approach versus the old one? If not, I wouldn't mind that this would be the default behaviour without adding extras flags.

@AlexanderEggers
Copy link
Contributor Author

AlexanderEggers commented Dec 13, 2019

@4brunu yep there is none. The new one improves the performance around converting json to objects + it does not use kotlin-reflects which reduces the project size by around 2-3mb. It should also simplify the usage of R8 (proguard). I would say that is significant.

Quote from the moshi repository readme:

"The JSON encoding of Kotlin types is the same whether using reflection or codegen. Prefer codegen for better performance and to avoid the kotlin-reflect dependency; prefer reflection to convert both private and protected properties."

I would still recommend keeping both to not break existing code and provide a choice for people in which method to use.

@4brunu
Copy link
Contributor

4brunu commented Dec 13, 2019

@Mordag thanks for the explanation, In this case, I think it's better to have a flag and let people choose which approach they prefer.
The PR looks good to me, thanks for the contribution 👍

@wing328
Copy link
Member

wing328 commented Dec 14, 2019

Tested locally and the result is good.

@wing328 wing328 merged commit 02f5cb1 into OpenAPITools:master Dec 14, 2019
@AlexanderEggers AlexanderEggers deleted the feature/moshi-codegen branch December 14, 2019 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants