* Support gradle incremental processing in code gen
This adds support for incremental compilation in gradle via incap helper and marking the code gen as `ISOLATING`.
Depends on a newer version of KotlinPoet that has https://github.com/square/kotlinpoet/pull/647Resolves#589
* Opportunistically update to auto-service 1.0-rc5
Supports incremental compilation and moves annotations to a separate artifact
* 1.2.0 final!
* Mark compiler embeddales as test only
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.
* 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
* Add kotlin-module with support for Kotlin data classes
* Naming and style changes to KotlinJsonAdapter.
Biggest changes:
* Attempt to support regular classes and data classes
* Avoid parameter hashing when indexing is sufficient for
constructor parameters
This isn't yet public API.
This relies on an unreleased Okio API.
This has a significant impact on performance. I measured parsing performance
improve from 89k ops/sec to 140k ops/sec on one benchmark.
