AutoValue: (Optionally) Add private no-arg constructor to generated classes about auto HOT 9 CLOSED

IMO, your feature request should be with your serialization framework for different construction strategies, not with AutoValue.

from auto.

I agree that Kryo should be able to construct object even without a no-arg constructor (and it might be able to with custom serializers), but it was just an example - I'm sure there are other libraries that use reflection to access a class's constructors, and in those cases AutoValue classes can't be used.

Now, for "regular" methods there's no problem since you can define them in the base (abstract) class, but you can't do that for constructors, so I do think there's value in somehow specifying that AutoValue should generate them.

from auto.

I just checked, and as I expected Kryo instantiates the object being deserialized through its private no-arg constructor and then sets its fields through reflection. It's possible to do this for the final fields that AutoValue generates, since Field.setAccessible allows you to override finalness (which bothers me but there it is). However I would not like to have to reason about the concurrent behaviour of objects built that way (do other threads see the new field values? when?). And, there's no way to validate the field values as you typically would in the static create method of the abstract class. So that's potentially a security hole.

The question of serialization is an important one and I've given it some thought. We already have some special-case code for GWT serialization. Could that be generalized in a way that would allow other serialization frameworks to function? For example, allowing users to generate other classes by supplying further templates for the Apache Velocity engine that AutoValue uses internally? I'm not satisfied that there's a solution whose benefit outweighs its complexity, though.

From looking at the Kryo documentation it does seem that there are mechanisms that could be used in generated code (https://github.com/EsotericSoftware/kryo#kryoserializable) if there were a way to teach AutoValue how.

from auto.

Seeing that this issue is still open, I just wanted to contribute by saying that you can create seralizers for your AutoValue classes. An example follows:

public class OntologyTermSerializer extends Serializer<OntologyTerm>  {
    public OntologyTermSerializer() {
        super();
    }

    @Override
    public void write(Kryo kryo, Output output, OntologyTerm ontologyTerm) {
        kryo.writeObject(output, ontologyTerm.id());
        kryo.writeObjectOrNull(output, ontologyTerm.source(), String.class);
    }

    @Override
    public OntologyTerm read(Kryo kryo, Input input, Class<OntologyTerm> aClass) {
        return OntologyTerm.create(kryo.readObject(input, String.class), kryo.readObjectOrNull(input, String.class));
    }

    public static void registerSerializers(final Kryo kryo) {
        final OntologyTermSerializer serializer = new OntologyTermSerializer();
        kryo.register(OntologyTerm.create("").getClass(), serializer);
    }
}

Where OntologyTerm is:

@AutoValue
public abstract class OntologyTerm {

    public abstract String id();

    @Nullable
    public abstract String source();

    public static OntologyTerm create(String id) {
        return create(id, null);
    }

    public static OntologyTerm create(String id, String source) {
        return new AutoValue_OntologyTerm(id, source);
    }
    ...
}

from auto.

Thanks, that's a very helpful tip for people running into this problem!

from auto.

No problem. The “magic” and where I stumbled a bit until I figured it out is the line:

kryo.register(OntologyTerm.create("").getClass(), serializer);

That links the actual AutoValue class to the abstract class.

from auto.

I was looking at the auto project overall, and thinking about a
documentation refresh, and this seems like a good candidate for a "tips and
tricks" page for auto-value.

On Thu, 28 May 2015 at 10:17 Alfonso Muñoz-Pomer Fuentes <
[email protected]> wrote:

No problem. The “magic” and where I stumbled a bit until I figured it out
is the line:

kryo.register(OntologyTerm.create("").getClass(), serializer);

That links the actual AutoValue class to the abstract class.

—
Reply to this email directly or view it on GitHub
#122 (comment).

from auto.

An auto generated builder can be used. Because, the generated builder class will have zero argument constructor with setter and getter methods. For example,

@AutoValue
public abstract class MyInfo {
    public MyInfo() {}
    public abstract String getUserName();
    public abstract String getPassword();
    public static Builder builder() {
        return new AutoValue_MyInfo.Builder();
    }

    public static Class<? extends Builder> builderClass() {
        return AutoValue_MyInfo.Builder.class;
    }

    @AutoValue.Builder
    public abstract static class Builder {
        public abstract Builder setUserName(String value);
        public abstract Builder setPassword(String value); 

        public abstract String getUserName();
        public abstract String getPassword();

        public abstract MyInfo build();
        public abstract Builder toBuilder();
    }
}

from auto.

I'd just like to throw my hat in and comment that I ran into the same issue using Avro for serialization.

from auto.