You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Adrian Cole (JIRA)" <ji...@apache.org> on 2014/10/22 23:46:34 UTC
[jira] [Assigned] (JCLOUDS-750) Replace hand-written domain classes
with Auto-Value ones
[ https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Cole reassigned JCLOUDS-750:
-----------------------------------
Assignee: Adrian Cole
> 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)