Repository navigation
Incorrect variance in hasItem matcher #436
Description
The hasItem matcher has the signature
Matcher<Iterable<? super T>> hasItem(Matcher<? super T> itemMatcher)but it should be
Matcher<Iterable<? extends T>> hasItem(Matcher<? super T> itemMatcher)because the matcher needs to read items from the Iterable and it needs the contract that the sequence contains at least items of type T, so it should be covariant in T
The current implementation states the opposite, it would be applicable it the matcher wanted to write to the iterable, but that is (a) not possible, since there is no write operation on an iterable and (b) not its usecase.
Reacted by Stanislav Spiridonov
Activity
foal commentedon Aug 6, 2025
I also faced this issue and had to use the patched version in my project - https://github.com/hortonolite/hamcrestBeanMatcherApt/blob/main/annotation/src/main/java/org/jresearch/hamcrest/beanmatcher/matcher/pecs/IsIterableContaining.java
foal commentedon Aug 6, 2025
Anyway isn't it solved by #252?
CarstenLeue commentedon Aug 11, 2025
True, but unfortunately only in the 3.1 version which has not been released, yet
arimu1 commentedon Aug 7, 2026
This looks like the same PECS/variance problem fixed on
masterby #422 (which closed #252).On current
master,hasItem/hasItemsalready use the covariant form requested here:(same for the value overload, and for
hasItemsreturningMatcher<Iterable<? extends T>>), inIsIterableContaining,Matchers, andCoreMatchers.That change is documented under unreleased 3.1 in
CHANGES.md(breaking signature change vs 3.0). Released 3.0 still hasIterable<? super T>.No further code change appears necessary on
master; remaining work is shipping 3.1 (or depending on amaster/snapshot build). This issue can be closed as already fixed pending release, or kept open purely as a release-tracking note.