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

Generated MoshiJsonAdapter is generated in wrong class #105

Closed
kmdupr33 opened this issue Apr 12, 2018 · 2 comments
Closed

Generated MoshiJsonAdapter is generated in wrong class #105

kmdupr33 opened this issue Apr 12, 2018 · 2 comments

Comments

@kmdupr33
Copy link

kmdupr33 commented Apr 12, 2018

I have a Kotlin auto-value class that implements parcelable and needs to be serialized by moshi. I'm using auto-value-parceleable and auto-value-moshi. I've followed the recommendation in issue #70 to include a @JvmStatic annotation on my jsonAdapter factory method. However, the MoshiJsonAdapter nested class is generated on $AutoValue_<class_name> instead of AutoValue_<class_name>.

That feels like a bug. My class looks like this:

@AutoValue
abstract class LockSelectionModel : Parcelable {
  abstract fun brand(): String
  companion object {
    @JvmStatic fun jsonAdapter(moshi: Moshi): JsonAdapter<LockSelectionModel> =
        `$AutoValue_LockSelectionModel`.MoshiJsonAdapter(moshi)
  }
}
@JakeWharton
Copy link
Contributor

This is working as intended, unfortunately.

AutoValue adds prefixes of an increasing number of $ symbols for the more extensions that apply to a single AutoValue type. In Java, you can reference nested classes from subtypes of the type in which the class is nested. Kotlin, however, does not allow this trick, which means that you must reference the nested class by directly referring to the class in which it was generated. What's also crazy, is that if you add a third extension to your project it might actually bump the JSON generator later in the chain and it would actually cause your build to fail because they have moved to $$AutoValue_LockSelectionModel.

@kmdupr33
Copy link
Author

wow. bummer. Thanks for clearing that up.

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

No branches or pull requests

3 participants