jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-750) Replace hand-written domain classes with Auto-Value ones
Date Sun, 02 Nov 2014 16:29:34 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193899#comment-14193899
] 

ASF subversion and git services commented on JCLOUDS-750:
---------------------------------------------------------

Commit 521a0c05f3e7ff5c91a28e73494d0b0091cb8aaf in jclouds-labs-google's branch refs/heads/master
from [~adrian.f.cole@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=521a0c0 ]

JCLOUDS-750 adjust for changes in @SerializedNames contract.


> 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)

Mime
View raw message