nacx commented on this pull request.
> +package org.jclouds.azurecompute.arm.domain;
+
+import com.google.auto.value.AutoValue;
+import com.google.common.collect.ImmutableList;
+import org.jclouds.javax.annotation.Nullable;
+import org.jclouds.json.SerializedNames;
+
+import java.util.List;
+
+@AutoValue
+public abstract class ExtensionProfileSettings {
+
+ /**
+ * The fileUris reference of the extension profile settings
+ */
+ @Nullable
In our domain objects, implemented with Google AutoValue, the `@Nullable`
annotation is taken into account inside the `AutoValue_` constructor. In these
cases, a `null` value will never get there, since we're always calling it with
a non-null value. The questions then re:
* If you need to be able to serialize this object and send it to the Azure API
**without** this field, then we need to follow the same approach we use with
the `tags`, and remove the annotation and initialize to "null or immutable", as
we want to explicitly support null.
* If there is no such a need of **sending** a null value, and it's only us
reading it, then we should think about how we want a Java API to look like for
users:
* Null collections is an anti-pattern, so we'd better enforce presence and
immutability. This helps to build a cleaner and easier to use API.
* In this case, as we're enforcing presence in the constructor, the
annotation is not required (if I'm not wrong), as it is only used by Google
AutoValue (and not for serialization/deserialization) and we're already taking
care of always passing a value.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/412#discussion_r147100384
