[
https://issues.apache.org/jira/browse/JCLOUDS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185107#comment-14185107
]
Adrian Cole commented on JCLOUDS-750:
-------------------------------------
Hi, [~zack-s] Thanks for joining the "nice, but" team :)
Here are answers to your questions.
1. Builders should not be put on output-only types. Since all types are output
types, you can save yourself and people like me who have to maintain other
people's code a lot of work by stopping doing that. Ex no user is constructing
a list of output types!
2. Builders construct classes which can often screw-up
equals/toString/nullable. We should not waste our time or our reviewer's time
creating or reviewing those.
3. Hand-crafted toString generation has already caused problems, including the
moreObjects vs Objects. Just because you didn't have to personally fix a ton of
classes or deal with broken merges last couple week, doesn't mean that didn't
happen. We shouldn't be adding runtime compatiblity problems like MoreObjects.
Anyway, here's an example type that uses a regular builder for now. Hope this
helps!
https://github.com/jclouds/jclouds-labs/blob/master/azurecompute/src/main/java/org/jclouds/azurecompute/domain/DeploymentParams.java
> 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)
