Moshi's initial code gen implementation used kotlin-metadata, but it had its downsides that were starting to show. Generated code will only use this reflective mechanism IFF the target model's constructor has any parameters with default values, otherwise it just invokes the regular constructor directly. We plan to remove the need for reflection by generating raw bytecode directly in the future, but can't do this just yet due to a bug in kapt. This makes code gen functionally at parity with the reflective KotlinJsonAdapter in this regard, albeit it does require a minimal bit of (cached) reflection to look up the synthetic constructor. data class Fox(val color: String, val winterColor: String = color) This case would not work prior to Moshi 1.9 Aside from avoiding the awkward double instantiation, this also allows for construction with dynamic parameter values. Previously, we had to use an awkward combination of the declared constructor + copy() to set the default properties.
How these constructors work merits a dedicated post in the future, but in short they accept some extra parameters to indicate which of the "real" parameters are actually present. In Moshi 1.9, generated adapters will now invoke constructors via the same synthetic constructor that Kotlin uses for constructors with default parameter values. Dynamic constructor invocation from code gen If you're worried about this, I suggest using Moshi 1.9 only in debug builds for a period of time to tease these out before releasing production builds with it. This is a potentially dangerous change! In projects using code gen, there are cases where Kotlin classes could have (appeared to) Just Work™️ before if you forgot to annotate them with These will fail at runtime now. Now, for Kotlin classes, you either need to use code gen, KotlinJsonAdapterFactory, or supply your own custom JsonAdapter. That's what KotlinJsonAdapterFactory or Kotlin code gen is for. ClassJsonAdapter's factory would best effort this, but at the end of the day it was not built to handle Kotlin classes and doesn't understand their behavior. Sometimes this worked fine, but many times it didn't and would fail in esoteric ways.
Before - if a Kotlin class was unhandled by any other JsonAdapter.Factory, it would fall through to ClassJsonAdapter. In 1.9, it will reject all Kotlin classes, not just ones in the kotlin.* package. classes in the kotlin.* package) for a while now. The built-in Java reflection ( ClassJsonAdapter.FACTORY) has rejected Kotlin platform types (i.e.
Java reflection will now reject Kotlin classes This would've caused unnecessary churn and noise for other tools that had nothing to with the issue and the issue was already fixed on master in Kapt and just waiting for the next release! With all this, we couldn't in good conscience release with that many caveats.
Java reflection get default constructor android#
If you get an obscure gradle compilation error not tied to a specific source, who's to blame? Moshi? Kapt? Gradle? Android gradle plugin? 🤷♂️. It would have been unclear which tool was at fault. Documentation is especially limited as a tool in annotation processing since users aren't actively looking at the processor source code itself. Prior to Kotlin 1.3.40, this wouldn't have worked at all and only partially worked until 1.3.50.
0 kommentar(er)
