[
https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188476#comment-14188476
]
Adrian Cole commented on JCLOUDS-750:
-------------------------------------
As a part of porting google storage
https://github.com/jclouds/jclouds-labs-google/pull/68, I noticed that
serialization for input types who are autovalue requires more work.
Serialization is addressed by our type hierarchy adapter
DeserializationConstructorAndReflectiveTypeAdapterFactory, which at the end of
the day looks at field types to determine how to serialize an object. It should
ideally look at the object itself, at least in the case of Auto-Value types, as
that's where the fields are.
More info below:
Ex.
When DeserializationConstructorAndReflectiveTypeAdapterFactory sees
`List<Foo>`, it ends up using the normal gson `ReflectiveTypeAdapterFactory` to
address Foo. ReflectiveTypeAdapterFactory looks at the declared type of the
fields and grabs all and works its way down. When the type is AutoValue, the
declared type has no fields (only abstract methods) , as the fields are in a
subclass called AutoValue_Foo. I will need to address this before we can
generally use auto for json apis.
> Replace hand-written domain classes with Auto-Value ones
> --------------------------------------------------------
>
> Key: JCLOUDS-750
> URL: https://issues.apache.org/jira/browse/JCLOUDS-750
> Project: jclouds
> Issue Type: New Feature
> Reporter: Adrian Cole
> Assignee: Adrian Cole
>
> In doing maintenance and ports, I've noticed that we have drift related to
> using guava to implement hashCode/equals on domain classes. Having an
> opportunity for a guava incompatibility on something like this is not high
> value, in my opinion. Moreover, we have a lot of other inconsistency in our
> value classes, which have caused bugs, and extra review time on pull requests.
> Auto-Value generates concrete implementations and takes out the possibility
> of inconsistency of field names, Nullability, etc. It is handled at compile
> time, so doesn't introduce a dependency of note, nor a chance of guava
> version conflict for our users.
> https://github.com/google/auto/tree/master/value
> While it may be the case that we need custom gson adapters (ex opposed to the
> ConstructorAnnotation approach), or a revision to our approach, I believe
> that this work is worthwhile.
> While it is the case that our Builders won't be generated, I still think this
> is valuable. For example, in many cases, we shouldn't be making Builders
> anyway (ex. they are read-only objects never instantiated, such as lists).
> Even if we choose to still write Builders, the problem is isolated there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
