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.
Move more behavior into the types: Adapter and Property now have many
instance methods and are now mutable value classes rather than immutable
data classes.
This changes how some of the bookkeeping code works. Previously there were
some pretty tricky types: maps with pairs as keys, indexed and non-indexed
lists of properties. With this change more of the logic operates directly
on the properties.
* Add kotlin code gen modules
* Update kotlin to 1.2
* Add a serializable dummy class
* Try using kapt configuration from kotlin-examples repo
Still no luck!
* Use proper allocated name for assignment too
* Use selectName() API
* Clean up constructor parameter annotations & plumbing for qualifiers
* Updates poms and kotlin code gen processor to support tests.
* Ignore kotlin code gen tests for now
None of these are data classes tests right now, which is the only thing this supports right now
* Replace $ with _ in class names for consistency
* Shortcut Array types to arrayOf
* Add DataClassTest
* Try generated option first, fall back to maven after
* More idiomatic handling
* Only use nonnullable types for adapter properties
* Code dump of kotshi tests
* Comment out specifics to get compiling
* Generics support!
* Fix double primitive default
* Pick up temporary snapshot for Any fix
* Invariance should just be null
* Better handling of nullably-bound variance
* Just assume the first jvm constructor for now as jvmMethodSig is flaky
* Specify types param if needed
* Don't do lazy delegation
* Clean up nullable typevariablename boundaries
* Add type variables to extension function on companion object
* Use properties instead of allocated names for more robustness
Since we're already on a snapshot
* If there are no type variables, make it null for simpler handling
* Fix generics and Type[] handling
* Fix unnecessary as casts on primitive defaults
* Reference spec directly for possible bangs
* Use nullSafe() adapters for anything nullable or with default values
* Use object type in makeType()
Types.java cares
* Make TestPrimitiveDefaultValues work
* Re-enable TestClassWithJavaKeyword
* Ignore remaining tests that are pending decisions or JsonQualifier support
* Remove customnames test as we're just going to stick with simple @Json
* Add toString() implementations
* Reenable default values testing, adapt to kotlin lang support
* Remove primitive adapters bits since we're not using it
* Clean up a bunch of leftover comments
* Switch to only nullable handling, report missing properties
This makes all nullable handling for local properties the same, and removes defaults for primitives in the process. It simplifies the handling a lot, and leans on kotlin language features to take care of null handling (null checking and then throwing the lazily evaluated list of missing properties).
One minor change from what kotshi does - this reports the serialized name in the missing properties, not the property name. We could look at supporting this though if we want.
* Implement JsonQualifier support
* Use Kapt for AutoService/processor declaration
* Checkstyle
* Remove unused primite type checks
* Add test verifying mutable and immutable collections work
* Fix test name
* Standardize isRequired checks
* Add more nullability and mutability tests
* Kotlinpoet 0.7.0 final
* Switch to new vararg overload for annotation class adapter()
* Make suffix just JsonAdapter without underscore
* Switch to just a regular constructor for MoshiSerializableFactory
* Remove constructor caching
* Remove unnecessary framework class checks
* Nix unnecessary superclass lookups, inline constructor lookup
* Nix null token check in reads
* Nix null check in writes, do !! on first value use
* Nix null checks in favor of serializeNulls
* Inline null checks and fail eagerly
* Fix double _Adapter
* First pass at simplifying adapter names
* Inline names to options property, life into class and rm companion
* Differentiate between absent and null, use nullSafe() as needed
* Group together compile and test dependencies
* Remove incorrect comment
* Revert formatting
* Set, not mutable set
* Collapse else-if nesting to one when
* Cleaner formatting test code
* Collapse more to locals
* Collapse more
* Return a nonnullable type in fromJson
* Remove redundant out variance
* Use KClass where appropriate
* End comment in period
* Remove redundant comment
* Throw on unrecognized type in simplified name
* Use illegalargumentexception instead
* Emit a nullcheck at the beginning of toJson instead
* Remove extra newline
* Simplify processing to be less abusive
* Skip using asClassName() when possible
* Use addComment()
* Switch to declared constructors
Technically more correct since we're defining these
* Unmodifiable set
* return adapter(type, annotationTypes[0])
* Slight optimization - check if the type is parameterized first
If the type is a parameterized type, then we know they'll have the two-arg constructor. This way we don't always try and fail the single arg constructor on parameterized types
* Add test for type aliases, optimize to reuse adapters if possible
This is a tiny optimization to make type aliases (which did already work) reuse adapter properties if they already exist for the backing type. What this means is that if you have:
typealias Foo = String
and properties
foo: Foo
bar: String
you'll only get one adapter property field for String, and both will use it
* Use string templating where possible
* Remove all the kotshi tests
