Skip to content
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

Use code gen for moshi adapters instead of reflection #673

Merged
merged 8 commits into from
May 15, 2022

Conversation

ZacSweers
Copy link
Contributor

Faster runtime performance plus it should resolve #667 along the way.

Couldn't use moshi-ir due to the low kotlin version here (it only supports Kotlin 1.6+) and lucked out that the first stable version of KSP happened to be the version of Kotlin this uses.

@@ -20,6 +21,7 @@ internal interface DependencyView<T> : Comparable<T> where T : DependencyView<T>
* nb: Deliberately does not implement [DependencyView]. For various reasons, this information gets embedded in
* [ExplodedJar], which is the preferred access point for deeper analysis.
*/
@JsonClass(generateAdapter = true)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is also used in serialization but wasn't annotated before, not sure if there's others but they'll need to be updated with this too unless you want to just defensively keep the reflection adapter

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just in general, why do some additional data classes and enum classes now need this annotation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since it's an annotation processor, it needs an annotation to process to know what to generate for. It also ends up being valuable for seeing at-a-glance which classes are relevant for JSON parsing, including enums. It's particularly useful in R8/proguard situations too as there are embedded rules to keep these.

@ZacSweers
Copy link
Contributor Author

I think I got 'em all

@@ -8,6 +8,7 @@ plugins {
id("org.jetbrains.kotlin.jvm")
`kotlin-dsl`
groovy
id("com.google.devtools.ksp") version "1.5.31-1.0.0"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would I remove this plugin once this todo was resolved?

// TODO switch to moshi-kotlin-codegen (where this was upstreamed to) once updated to Moshi 1.13.0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope you would just switch the Moshi-KSP dep below with mainline Moshi code gen instead. Though if you can go to kotlin 1.6 in that case, you could replace this with Moshi-IR instead and remove KSP all together

Copy link
Owner

@autonomousapps autonomousapps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think this is for the best, to make the serialization model more explicit.

@autonomousapps autonomousapps merged commit 604d785 into autonomousapps:main May 15, 2022
@ZacSweers ZacSweers deleted the z/codegenMoshi branch May 16, 2022 03:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NoSuchMethodError: kotlinx.metadata.jvm.KotlinClassHeader.<init>
2 participants