-
-
Notifications
You must be signed in to change notification settings - Fork 124
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
Conversation
@@ -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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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.
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.