Overloading a Builder's method for mass-adding to a Singular field removed the default convenience methods

[CarlSalaets]

For a @Singular List<E> elements the @Builder generates 3 convenience methods:

• element(E element)
• elements(Collection<? extends E> elements)
• clearElements()

but if I try to overload the collection setter it no longer generates these 3 methods.

@Builder
public class BuilderExample {
    @Singular
    public List<String> elements

    public static class BuilderExampleBuilder {

        /*
         * This overloaded method prevents the generation of the default methods.
         */
        public BuilderExampleBuilder elements(Stream<String> elementStream){
            return elements(elementStream.collect(toList()));
        }

        /*
         * This overloaded method is fine; it does not prevent the generation of the default methods.
         */
        public BuilderExampleBuilder element(Integer elementOfAnotherType){
            return element(String.valueOf(elementOfAnotherType));
        }

    }
}

Note: I'm not overwriting the generated methods, I'm overloading them to accept different types of arguments.

[rspilker]

I would have expected and error saying Manually adding a method that @Singular @Builder would generate is not supported. If you want to manually manage the builder aspect for this field/parameter, don't use @Singular.

As far as I can see from the code, it only looks at the method names. One of the reasons is that it is very hard for us to see if you've created an overload or a replacement method. The latter will not really work since we have an (on purpose) undocumented internal representation that is optimized for further processing.

[Maaartinus]

@rspilker I see the error you mentioned. However, overloads should be supported with @Tolerate. This is a typical use case for it, but it seems to be ignored, so I'd suggest to reopen.

[CarlSalaets]

@Tolerate is still experimental for now, But that would be a good way to mitigate this issue.

[jmoraleda]

I have encountered this exact issue. Currently I work around it by using a different name for the method I write that takes a different the of arguments from the method that lombok generates, but being able to overload the lombok method would create a cleaner interface. IMHO, I concur with the suggestion that explicitly annotating the manually created method with @Tolerate would be a good compromise.

[jmoraleda]

I remark that this issue is a duplicate of the older (albeit less well documented and commented on) #1498