jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Cole (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCLOUDS-750) Replace hand-written domain classes with Auto-Value ones
Date Sat, 01 Nov 2014 19:47:33 GMT

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

Adrian Cole edited comment on JCLOUDS-750 at 11/1/14 7:47 PM:
--------------------------------------------------------------

Recap.

So, you now specify a SerializedNames annotation on an auto-value builder. This controls the
naming convention, especially those annoying ones like IPAddress vs IpAddress. 

Side-notes, but 
  1. please don't create builders for output-only types.
  2. For input-types, where parameter list is over 3, a builder may still make sense. In that
case, still create the factory method, and use that in your builder.
  3. Use Nullable instead of Optional. Using Optional inconsistently is worse than Nullable,
and inconsistent has become status quo. Since Optional also conflicts in Java 8 (as well other
jvm langs), just use Nullable.

Here's an example complete type, complete with odd-naming convention.
{code}
@AutoValue
public abstract class NetworkSettings {
   public abstract String ipAddress();
   @Nullable public abstract String portMapping();

   @SerializedNames({ "IPAddress","PortMapping" })
   public static NetworkSettings create(String ipAddress, String portMapping) {
      return new AutoValue_NetworkSettings(ipAddress, portMapping);
   }
}
{code}


was (Author: adriancole):
Recap.

So, you now specify a SerializedNames annotation on an auto-value builder. This controls the
naming convention, especially those annoying ones like IPAddress vs IpAddress. 

Side-notes, but 
  1. please don't create builders for output-only types.
  2. For input-types, where parameter list is over 3, a builder may still make sense. In that
case, still create the factory method, and use that in your builder.
  3. Use Nullable instead of Optional. It is worse to use it inconsistently than using Nullable.
Since Optional conflicts in Java 8 (as well other jvm langs), just use Nullable.

Here's an example complete type, complete with odd-naming convention.
{code}
@AutoValue
public abstract class NetworkSettings {
   public abstract String ipAddress();
   @Nullable public abstract String portMapping();

   @SerializedNames({ "IPAddress","PortMapping" })
   public static NetworkSettings create(String ipAddress, String portMapping) {
      return new AutoValue_NetworkSettings(ipAddress, portMapping);
   }
}
{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)

Mime
View raw message