[
https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184569#comment-14184569
]
Adrian Cole edited comment on JCLOUDS-750 at 10/26/14 5:57 PM:
---------------------------------------------------------------
Ok current progress assuming the above is in.
Use this form to address json and make sure you bind an appropriate
FieldNamingPolicy, if the names you use aren't lower-camel!
{code}
bind(FieldNamingPolicy.class).toInstance(FieldNamingPolicy.LOWER_CASE_WITH_DASHES);
--snip--
@SerializedNames({ "id", "content-type" })
public static SpinalCasedType create(String id, String contentType) {
{code}
Here are some caveats to keep in mind.
1. Auto encourages a flat value-type hierarchy, or composition. There are cases
where we define a base type, such as Resource, which is used to avoid
duplicating work on each value object. In order to use auto, you would need to
not do that. In many cases the fields on base types are never used, and in
other cases, it will be better to just duplicate the accessors with Auto vs
maintain the hierarchy. For example, in google I am going to suggest we flatten
the value type hierarchy as only the id is necessary from it.
2. You can now bind FieldNamingPolicy to address json standards such as snake
case. Albeit very very rare, some apis have mixed default casing. For example,
ApiMetadata.media-types in keystone vs RouterInterface.subnet_id in neutron.
This is so rare (ex in keystone, I can only find one example), that you can
special case serialization with a type adapter for the ones that mismatch.
was (Author: adriancole):
Ok current progress assuming the above is in.
Use this form to address json and make sure you bind an appropriate
FieldNamingPolicy, if the names you use aren't lower-camel!
{code}
@SerializedNames({ "id", "content-type" })
public static SpinalCasedType create(String id, String contentType) {
{code}
Here are some caveats to keep in mind.
1. Auto encourages a flat value-type hierarchy, or composition. There are cases
where we define a base type, such as Resource, which is used to avoid
duplicating work on each value object. In order to use auto, you would need to
not do that. In many cases the fields on base types are never used, and in
other cases, it will be better to just duplicate the accessors with Auto vs
maintain the hierarchy. For example, in google I am going to suggest we flatten
the value type hierarchy as only the id is necessary from it.
2. You can now bind FieldNamingPolicy to address json standards such as snake
case. Albeit very very rare, some apis have mixed default casing. For example,
ApiMetadata.media-types in keystone vs RouterInterface.subnet_id in neutron.
This is so rare (ex in keystone, I can only find one example), that you can
special case serialization with a type adapter for the ones that mismatch.
> 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)
