Unable to generate AutoValue for a class with only boolean variables

[kndarp]

Using AutoValue 1.7.4

Failed to create an AutoValue class with builder for only boolean variable(s) in class. I observed this behaviour for 2 naming patterns - 'isXxx' and 'getXxx'. It works fine for 'xxx'.

Also, this does't fail when there is another variable of another type present in the class.

Failing code

@AutoValue
public abstract class AutoValueFails {
  
  AutoValueFails() {}

  public static Builder builder() {
    return new AutoValue_AutoValueFails.Builder();
  }

  public abstract boolean isBoolean();


  @AutoValue.Builder
  public abstract static class Builder {
    Builder() {}
        public abstract Builder isBoolean(final boolean value);
    }
}

Error :

Method does not correspond to a property of AutoValueFails
    public abstract Builder isBoolean(final boolean value);

Passing Code

@AutoValue
public abstract class AutoValuePasses {
  
  AutoValuePasses() {}

  public static Builder builder() {
    return new AutoValue_AutoValuePasses.Builder();
  }

  public abstract boolean isBoolean();
  public abstract String aString();


  @AutoValue.Builder
  public abstract static class Builder {
    Builder() {}
        public abstract Builder isBoolean(final boolean value);
    }
   Builder() {}
        public abstract Builder aString(final String value);
    }

}

[kndarp]

@ruchirsachdeva

[eamonnmcmanus]

The documentation says:

Some developers prefer to name their accessors with a get- or is- prefix, but would prefer that only the "bare" property name be used in toString and for the generated constructor's parameter names.

AutoValue will do exactly this, but only if you are using these prefixes consistently. In that case, it infers your intended property name by first stripping the get- or is- prefix, then adjusting the case of what remains as specified by Introspector.decapitalize.

That's what you're seeing here. In the first example, all of the properties (all one of them) look like isFoo, so they are assumed to follow the JavaBeans conventions. The single property method in AutoValueFails is called isBoolean() so the property is called boolean and it must be set by a builder method setBoolean(boolean x) or just boolean(boolean x) (ignoring for now that boolean is a keyword). If you add a second property method aString() then it is no longer the case that all the methods follow the JavaBeans conventions, so the properties are now isBoolean and aString and they are set by methods setIsBoolean(boolean x) and setAString(String x) or isBoolean(boolean x) and aString(String x).

This is admittedly a bit tricky. AutoValue does contain code that attempts to detect when someone runs into this problem but unfortunately you must not have triggered it in your experiments.

If you can think of a documentation change that would have made it easier for you to find this then we would certainly appreciate that.