[
https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184327#comment-14184327
]
Adrian Cole commented on JCLOUDS-750:
-------------------------------------
Also, if you need custom type adapters, they will need to be type hierarchy
factories (as autovalue writes a subtype). Here's an example superclass I made
in oauth.
{code}
import com.google.gson.Gson;
import com.google.gson.TypeAdapter;
import com.google.gson.TypeAdapterFactory;
import com.google.gson.reflect.TypeToken;
/**
* Type adapter used to serialize all subtypes of a value. This can be used to
force serialization for an {@link
* com.google.auto.value.AutoValue} generated class.
*/
public abstract class SubTypeAdapterFactory<T> extends TypeAdapter<T>
implements TypeAdapterFactory {
private final Class clazz;
protected SubTypeAdapterFactory() {
// As long as the implementing type is not parameterized, this can steal
type T
this.clazz = Class.class.cast(new
com.google.common.reflect.TypeToken<T>(getClass()) {
private static final long serialVersionUID = 1L;
}.getRawType());
}
/** Accepts duty for any subtype. When using AutoValue properly, this will
be the generated form. */
@Override public <T> TypeAdapter<T> create(Gson gson, TypeToken<T>
typeToken) {
if (!(clazz.isAssignableFrom(typeToken.getRawType()))) {
return null;
}
return (TypeAdapter<T>) this;
}
}
{code}
> 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)
