aa027af causes compile errors

[Mads Baardsgaard]

Hello, The aforementioned commit is preventing me from upgrading from v33 to v34. The issue:

I have a quite simple record which should create a builder:

public record CombinedFields(
    @JsonValue String combinedField,
    List<CombinedFieldsLine> lines) implements CombinedFieldsBuilder.Bean {}

But now, the generated builder contains a setter with an undefined method (shim?)

    /**
     * Re-create the internally allocated {@code List<CombinedFields.CombinedFieldsLine>} for {@code lines} by copying the argument
     */
    @Generated("io.soabase.recordbuilder.core.RecordBuilder")
    public CombinedFieldsBuilder setLines(
            Collection<? extends CombinedFields.CombinedFieldsLine> lines) {
        this.lines = __list(lines);
        return this;
    }

It's this __list method that does not exist. Is this a bug or something I need to change in my configuration?

[Jordan Zimmerman]

Can you please post the entire source for CombinedFields so we can have a complete test case? In particular, we need to know the RecordBuilder.Options being used.

[Mads Baardsgaard]

Hi, my Options follows. I made this custom annotation for it to avoid repetition

@RecordBuilder.Template(options = @RecordBuilder.Options(
    enableWither = false,
    enableGetters = false,
    addConcreteSettersForOptional = true,
    addSingleItemCollectionBuilders = true,
    booleanPrefix = "is",
    getterPrefix = "get",
    setterPrefix = "set",
    beanClassName = "Bean"))
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.TYPE)
@Inherited
public @interface RecordStyle {

}

[Jordan Zimmerman]

It seems this was only tested when useImmutableCollections=true was also used. What do you think about addSingleItemCollectionBuilders = true also implying useImmutableCollections=true?

[Johannes]

Sidenote: the JavaDoc for the setter methods also mentions the creation of a copy of the collection instead of just setting it:
* Re-create the internally allocated {@code Set<T>} for {@code mySet} by copying the argument
That should be adjusted as well if useImmutableCollections = false.

[Jordan Zimmerman]

@tmichel any thoughts on this?

[Jordan Zimmerman]

@tmichel are you around? I'd appreciate your thoughts on this issue.

[Tamás Michelberger]

I feel that one setting implying another is really not intuitive. If possible any combination of options should work. Although I believe the implementation complexity comes from the interaction of features.

I believe when the addSingleItemCollectionBuilders is true the builder should maintain its own collection instance. The setter method breaks encapsulation in this case so maybe remove the option to overwrite the collection and only allow adding and clearing items. Then even the performance characteristics are clearer.

Basically instead of builder.setLines(...) only allow builder.clearLines().addLines(iterable).

I know that this is a breaking change in the API so this might not be so straightforward to introduce. I could see that if addSingleItemCollectionBuilders causes this many issues then it could be deprecated and a different option be introduced so that single collection builders and simple setters generate two distinct builder APIs. I guess the option could be useSingleItemCollectionBuilders.

useImmutableCollections should only affect whether the final collection during the build is an immutable copy of the internal collection or not.

[Jordan Zimmerman]

Hey folks - please review #130