You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spring Batch 5.1.1's ListItemWriter<T>::getWrittenItems has the bounded wildcard generic return type List<? extends T>. It is evident from the field's type, List<T>, that the method return type's bounded wildcard contributes nothing of value, but besides this some constructs end up inferring the specific element type ? extends T where only a T can work, necessitating otherwise redundant explicit type parameter specification. This ergonomics breakage manifests trivially in AssertJ's ListAssert<ELEMENT>, which happens to feature an API that appears counter-productively genericized, but it is easy to show with plain JDK APIs that the correct return type should be List<T>; consider:
importjava.util.*;
classT {
voidfoo() {
varwriter = newLiWr<Element>();
varwithout = writer.itemsWithoutWildcard(); // List<Element>varmutableWithout = newArrayList<>(without); // ArrayList<Element>mutableWithout.add(newElement());
// T.java:18: error: incompatible types: Element cannot be converted to CAP#1// mutableWith.add(new Element());// ^// where CAP#1 is a fresh type-variable:// CAP#1 extends Element from capture of ? extends Elementvarwith = writer.itemsWithWildcard(); // List<? extends Element>varmutableWith = newArrayList<>(with); // ArrayList<? extends Element>mutableWith.add(newElement());
// T.java:25: error: incompatible types: List<CAP#1> cannot be converted to List<Element>// List<Element> with2 = writer.itemsWithWildcard(); // List<? extends Element>// ^// where CAP#1 is a fresh type-variable:// CAP#1 extends Element from capture of ? extends ElementList<Element> with2 = writer.itemsWithWildcard(); // List<? extends Element>// okvarwith3 = writer.itemsWithWildcard();
List<Element> mutableWith2 = newArrayList<>(with);
}
}
classLiWr<T> {
finalList<T> writtenItems = newArrayList<>();
List<? extendsT> itemsWithWildcard() { returnthis.writtenItems; }
List<T> itemsWithoutWildcard() { returnthis.writtenItems; }
}
classElement {}
Effective Java 3rd Ed. item 32 also says
Do not use bounded wildcard tyeps as return types.
The text was updated successfully, but these errors were encountered:
Spring Batch 5.1.1's
ListItemWriter<T>::getWrittenItems
has the bounded wildcard generic return typeList<? extends T>
. It is evident from the field's type,List<T>
, that the method return type's bounded wildcard contributes nothing of value, but besides this some constructs end up inferring the specific element type? extends T
where only aT
can work, necessitating otherwise redundant explicit type parameter specification. This ergonomics breakage manifests trivially in AssertJ'sListAssert<ELEMENT>
, which happens to feature an API that appears counter-productively genericized, but it is easy to show with plain JDK APIs that the correct return type should beList<T>
; consider:Effective Java 3rd Ed. item 32 also says
The text was updated successfully, but these errors were encountered: