Collection-valued property exposed as immutable causes compile error about auto-value-moshi HOT 4 CLOSED

This is tricky to support, because AutoValue just special-cases immutable collections and does a bunch of things under the hood to check if it's applicable. On top of that, not all of them are types that we can reasonably support. Here's another case that autovalue supports that we can't:

@JsonClass(generateAdapter = true, generator = "avm")
@AutoValue
public abstract class Foo {
    public abstract ImmutableList<String> getBar();

    public static Builder builder() {
        return new AutoValue_Foo();
    }

    @AutoValue.Builder
    public abstract static class Builder {
        public abstract Builder setBar(String... barElements);
        public abstract Foo build();
    }
}

It is supported by the underlying overloads of ImmutableSet.copyOf(...), but we can't reuse that infrastructure here the way autovalue can. I think the only safe solution we can suggest is to declare a second setter with the exact type.

from auto-value-moshi.

Thanks, that makes a lot of sense. Auto-value-moshi 0.4.7 didn't seem to have this problem... I'm assuming because the builder was not used for deserialization. In my use case, I only need to serialize. It might be nice if there was a way to have certain properties be ignored for serialization or deserialization only, and thereby negating the mismatched types issue. At present, it seems that @AutoTransient acts on the property during both serialization and deserialization.

from auto-value-moshi.

Moshi intends to be symmetric. The “only one type of serialization” idea has been discussed many times and every time the conclusion is the same: write your own adapter if you don’t want a symmetric library to be symmetric :)

from auto-value-moshi.

Fair enough, thanks.

from auto-value-moshi.