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

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.

[AlexanderEggers]

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]

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]

@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]

@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]

Tested locally and the result is good.