Document using Kotlin Serialization or Moshi instead #2857
Conversation
README.md
Outdated
| > [!IMPORTANT]\ | ||
| > Gson is not a recommended library for interacting with JSON on Android. The open ended reflection in the Gson runtime doesn't play nicely with shrinking/optimization/obfuscation passes that Android release apps should perform.\ | ||
| > If your app or library may be running on Android, instead look at [Kotlin Serialization](https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/basic-serialization.md#basics) which uses code generation instead of reflection. This avoids Gson's runtime crashes when optimizations are applied, and results in faster performance on Android devices. If you still want to use Gson and attempt to avoid these crashes, you can see how to do so [here](Troubleshooting.md#-proguard--r8). | ||
| > If your app or library may be running on Android, consider using [Kotlin Serialization](https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/basic-serialization.md#basics) or [Moshi](https://github.com/square/moshi), which use code generation instead of reflection. This avoids Gson's runtime crashes when optimizations are applied, and results in faster performance on Android devices. If you still want to use Gson and attempt to avoid these crashes, you can see how to do so [here](Troubleshooting.md#-proguard--r8). |
There was a problem hiding this comment.
I don't think we can recommend Moshi unreservedly. By default it uses reflection, which is just as problematic on Android as with Gson, for the same reasons. So at least I think the text would have to say "Moshi codegen" and link to the codegen section of the documentation.
I'd also like to have something to help readers decide which solution is more appropriate for them. What would lead someone to choose Moshi over kotlinx.serialization?
There was a problem hiding this comment.
https://github.com/square/moshi?tab=readme-ov-file#codegen is only for KSP for Kotlin, I didn't paste it as Moshi also supports APT for Java.
There was a problem hiding this comment.
Could you write something like this?
consider a solution that uses code generation instead of reflection, such as [Kotlin Serialization](...) or Moshi with codegen (for Java](...) or [Kotlin](...)).
I don't see where Java codegen is documented on the Moshi site, though I do see this separate project. Is that what you're referring to? If we're talking about how people can assemble other projects in order to avoid reflection, we might also reference auto-value-gson. That could be a separate change, though.
I still think that we would need to tell people why they might consider using Moshi codegen with Kotlin instead of the solution that is built in to the Kotlin platform.
There was a problem hiding this comment.
Ooops, I misremembered that...
Moshi's official code generation has only been available for Kotlin from the start, initially via KAPT (which is based on APT). I used it in my projects through KAPT instead of APT.
There was a problem hiding this comment.
Updated the doc!
I still think that we would need to tell people why they might consider using Moshi codegen with Kotlin instead of the solution that is built in to the Kotlin platform.
Also amended the reason for it,
... when optimizations are applied (usually due to the fields missing or obfuscating)
Co-authored-by: Marcono1234 <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
eamonnmcmanus
left a comment
There was a problem hiding this comment.
I am still reluctant to make this change unless we can say why someone would want to use Moshi-codegen with Kotlin instead of the solution that is proposed and supported by JetBrains. I can believe there would be reasons, but can we say what they are?
|
Moshi's APIs share similarities with Gson, making it easier and more seamless for users to migrate between the two. |
OK, do you want to add a sentence like this after the "This avoids..." sentence?
|
|
Done. |
Description
Refs #2856 (comment).
Checklist
This is automatically checked by
mvn verify, but can also be checked on its own usingmvn spotless:check.Style violations can be fixed using
mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.null@since $next-version$(
$next-version$is a special placeholder which is automatically replaced during release)TestCase)mvn clean verify javadoc:jarpasses without errors