Deprecate APIs that use Hamcrest classes. Users should use java-hamcrest by kcooney · Pull Request #1150 · junit-team/junit4 (original) (raw)

Well, the classes were copied from JUnit to hamcrest-junit so people could migrate by just changing imports. So the confusion is unavoidable. I do know projects that use these classes without Hamcrest, so I wouldn't want to remove them. If you think that having these classes have the same name is confusing, then maybe you could ask the Hamcrest team to rename their versions.

Truth already supports assumptions and checks (I believe without subclassing our classes):

assume().that(actualList).contains(3);

Perhaps we should ask the Hamcrest team if they would need a Check class.

If we add a Check class we would need to define generics of the API extremely carefully. Can a Check<Number> be used to do assertions on an Integer? How would one use a Check to check that a Number is a Long?

Edit: BTW, I don't think Java 8 users should be using the ExpectedException class at all. We should add methods to Assert, ErrorCollector and Assume that allow passing in a lambda and the expected exception type, possibly as soon as JUnit 5