Otherwise, Moshi.adapter(null) will end up calling into user JsonAdapter factories with a null Type parameter.
Kotlin fails with java.lang.IllegalArgumentException: Parameter specified as non-null is null
That message ends up too far away from the real error.
Currently our main loop to gather PropertyGenerators goes over the backing fields.
This needs to change to iterate over the properties themselves. That leads to a lot
of churn. The net result is slightly more compatibility with the reflective adapter.
* Generate `@Generated` annotation onto adapters when possible
Part of #461
This leverages AutoCommon's `GeneratedAnnotations#generatedAnnotation` API to generate a `@Generated` annotation where possible. This keeps with conventions in other code gen tools, and also allows for more fine grained proguard rules for keeping generated adapter names, like so:
```proguard
-keepnames @com.squareup.moshi.<wherever this ends up>.MoshiSerializable class *
# Java < 9
-keepnames @javax.annotation.Generated class **JsonAdapter
# Java 9+
-keepnames @javax.annotation.processing.Generated class **JsonAdapter
```
Generated annotation looks like this:
```kotlin
@Generated(
value = ["com.squareup.moshi.MoshiKotlinCodeGenProcessor"],
comments = "https://github.com/square/moshi"
)
```
This doooooes also replace `elements` in `AdapterGenerator` with a `ProcessingEnv`, but I figured that was less evil than polluting it with both `elements` and plumbing down an `env` separately simultaneously. This does also hit a weird ambiguity case due to `KotlinMetadataUtils`' repeat declaration, so a good reason for removing that in the future. Figured it best to punt on a better final place for this to another time.
* Remove names and brackets
* Add moshi.generated option
* Switch back to element property rather than processingEnv
* Fold the kotlin-codegen-runtime into Moshi itself.
Rename @MoshiSerializable to @JsonClass. Like @Json, I'm anticipating
a future where there are other interesting properties on this annotation.
Perhaps a future feature where Moshi is strict and only adapts types that
have a '@JsonClass' annotation.
Also rename MoshiKotlinCodeGenProcessor to JsonClassCodeGenProcessor. We
may later support other ways of generating code here; perhaps for regular
Java types.
* Generate `@Generated` annotation onto adapters when possible
Part of #461
This leverages AutoCommon's `GeneratedAnnotations#generatedAnnotation` API to generate a `@Generated` annotation where possible. This keeps with conventions in other code gen tools, and also allows for more fine grained proguard rules for keeping generated adapter names, like so:
```proguard
-keepnames @com.squareup.moshi.<wherever this ends up>.MoshiSerializable class *
# Java < 9
-keepnames @javax.annotation.Generated class **JsonAdapter
# Java 9+
-keepnames @javax.annotation.processing.Generated class **JsonAdapter
```
Generated annotation looks like this:
```kotlin
@Generated(
value = ["com.squareup.moshi.MoshiKotlinCodeGenProcessor"],
comments = "https://github.com/square/moshi"
)
```
This doooooes also replace `elements` in `AdapterGenerator` with a `ProcessingEnv`, but I figured that was less evil than polluting it with both `elements` and plumbing down an `env` separately simultaneously. This does also hit a weird ambiguity case due to `KotlinMetadataUtils`' repeat declaration, so a good reason for removing that in the future. Figured it best to punt on a better final place for this to another time.
* Fix rebase conflicts and sync with remote
This is towards making the reflection and codegen adapters work the same.
The process is relatively straightforward: try to promote all of the tests
in KotlinCodeGenTest to be passing tests in GeneratedAdaptersTest or
compile failures in CompilerTest
Rename @MoshiSerializable to @JsonClass. Like @Json, I'm anticipating
a future where there are other interesting properties on this annotation.
Perhaps a future feature where Moshi is strict and only adapts types that
have a '@JsonClass' annotation.
Also rename MoshiKotlinCodeGenProcessor to JsonClassCodeGenProcessor. We
may later support other ways of generating code here; perhaps for regular
Java types.
