[BUG] @SuperBuilder/@Builder generates names(Collection<? extends String > names)-method, but String is final

[henrykuijpers]

Describe the bug
When using

@Singular
private final Collection<String> names;

A builder method

B names(Collection<? extends String> names)

is generated.

However, String is final, therefore the ? extends is not needed.

The Java compiler generates a warning:

name clash: names(java.util.Collection<? extends java.lang.String>) in nl.DefaultItem.Builder and names(java.util.Collection<java.lang.String>) in nl.ItemBuilder have the same erasure, yet neither overrides the other

Expected fix
Add a case for final classes, to not generate the wildcard.

Expected behavior
Generate B names(Collection<String> names)

Version info (please complete the following information):

• Latest Lombok

Additional context
Add any other context about the problem here.

[rspilker]

To determine if a class is final, we would need to use resolution. Although we have resolution in some places, as far as I know it's not reliable.

[henrykuijpers]

@rspilker Okay, in what cases is resolution not reliable? And do you have any examples of resolution?
I tried to come up with a PR, but I was not able to properly set up the codebase, so I had no code completion etc.

I would like to continue on this soon and I could use more information about resolution. Maybe it is possible. Maybe not -- but I'd like to figure that out. :)

[janrieke]

Have a look at the wiki:

If you have "package c; import a.b.*;" in your file, and class "c.Baz" exists, then a class reference to class "Baz" in this file is a reference to "c.Baz", but if you ask lombok's own resolver if this "Baz" reference is a reference to "a.b.Baz", lombok answers 'yes', eventhough it should have answered 'no'.

In this case it means that you could detect a class as final, but in fact the resolver was wrong and it is another class that is not final. In this case, you would generate wrong code.