Open GoogleCodeExporter opened 8 years ago
I think you are using a jdk 1.5, no ?
Original comment by cvgav...@gmail.com
on 29 Jan 2012 at 4:35
$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Should that make a difference?
Original comment by john.sm...@wakaleo.com
on 29 Jan 2012 at 7:16
- JVM version does make a difference
- Not sure whether this is fixable without breaking something else. Need to
pair with someone on this.
Original comment by smgfree...@gmail.com
on 25 Apr 2012 at 11:08
Just checked - this issue is still present in Hamcrest 1.3
Original comment by john.sm...@wakaleo.com
on 11 Jul 2012 at 10:53
[deleted comment]
Seems like a similar issue did hit SWTBot. SWTBot is built on Hamcrest 1.1, but
having it using Hamcrest 1.3 caused breakage:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=404346
Original comment by mickael.istria
on 26 Mar 2013 at 10:09
java version "1.6.0_51"
I just upgraded to JUnit4 4.11 and hamcrest 1.3 and the method hasItem( <some
matcher>) does not work at all.
I get the error:
cannot find symbol
symbol : method
assertThat(java.util.List<com.xoom.domain.model.TrackingStatusConfiguration>,org
.hamcrest.Matcher<java.lang.Iterable<? super java.lang.Object>>)
I am attaching the test file.
I originally had the matcher as an anonymous class, I then converted it to a
private static class, and somehow the Matcher returns a "...? super Object"
instead of a "... ? super SOMECLASS".
I have a bunch of anonymous classes using custom matchers.
DO you have a recommendation on how to temporarily make this work?
Original comment by gisel...@yachay.net
on 28 Oct 2013 at 3:51
Attachments:
I found quite ugly but working solution:
List<String> colors = Arrays.asList("red", "green", "blue");
assertThat(colors, Matchers.<String>hasItem(is("red")));
Original comment by eugene.beschastnov@gmail.com
on 15 Apr 2014 at 1:19
Same story here. What makes it a bit more interesting is the fact that Eclipse
JDT compiles the code just fine (compiler compliance level set to 1.6), without
the need to use such a hacky workaround demonstrated by Eugene.
Original comment by Pawel.Ra...@gmail.com
on 22 May 2014 at 10:06
Original issue reported on code.google.com by
wakaleo@gmail.com
on 12 Dec 2011 at 11:05