Getting NoSuchMethodError: org.hamcrest.Matcher.describeMismatch when running test in IntelliJ 10.5
The problem was that the wrong hamcrest.Matcher
, not hamcrest.MatcherAssert
, class was being used. That was being pulled in from a junit-4.8 dependency one of my dependencies was specifying.
To see what dependencies (and versions) are included from what source while testing, run:
mvn dependency:tree -Dscope=test
JMock- java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch()
You should make sure the compatibility of libraries(jars). If a class inside jar uses some method from class which is in another jar, and this used method is newly added and you are using old jar then definitely you will get java.lang.NoSuchMethodError
.
NoSuchMethodError with Hamcrest 1.3 & JUnit 4.11
This blog helped fix the same problem for me:
https://tedvinke.wordpress.com/2013/12/17/mixing-junit-hamcrest-and-mockito-explaining-nosuchmethoderror/
Inside the dependencies for Mockito and Junit, the author added excludes:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<exclusions>
<exclusion>
<artifactId>hamcrest-core</artifactId>
<groupId>org.hamcrest</groupId>
</exclusion>
</exclusions>
</dependency>
NoSuchMethodError with Hamcrest 1.3 and Maven on GAE
TestNG has a dependency on JUnit. Therefore junit-4.10.jar is in your class path. This Jar includes Hamcrest classes that are older than Hamcrest 1.3 and are missing some methods. The classloader loads org.hamcrest.core.IsInstanceOf
from JUnit and therefore you're running into problems.
Add a dependency to JUnit 4.11 to your POM. This overrides TestNG's dependency to JUnit 4.10 and solves your Hamcrest problems, because JUnit 4.11 no longer includes Hamcrest classes.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
NoSuchMethodError when using assertThat+is with data type short
The signature of assertThat()
is assertThat(T actual, org.hamcrest.Matcher<T> matcher)
T in your case is: short
So you need a Matcher<Short>
. But 0 is an int literal. So you have to tell the compiler: use that int value as short.
Although it would be perfectly fine to turn 0-int into 0-short, Java isn't smart enough. As you are "restricting" something from the int range to short range, you have to put down that cast.
Related Topics
How to Configure Jackson in Wildfly
Java Error Opening Registry Key
Converting Integer to String with Comma for Thousands
How to Access Resources in Jar File
Java Swing: How to Change Gui Dynamically
Why Can't Primitive Data Types Be "Null" in Java
What Is the Point of Setters and Getters in Java
How Is Hashcode() Calculated in Java
Why Are the Rsa-Sha256 Signatures I Generate with Openssl and Java Different
What Is the Cross-Platform Way of Obtaining the Path to the Local Application Data Directory
Hiding Instance Variables of a Class
How to Sort an Arraylist of Objects by a Property
Instanceof - Incompatible Conditional Operand Types
Why Is an Array Not Assignable to Iterable