peterdemaeyer / javahamcrest Goto Github PK

There are some obsolete modules in the JavaHamcrest project that should be removed: hamcrest-core, hamcrest-library, hamcrest-integration.

"Is" is about object identity, corresponding to the == Java operator.
"Is equal to" is about object equality, corresponding to the equalTo method.
Hamcrest 2.x gets these semantics wrong because it defaults the Is matcher to the semantics of equalTo.
To fix this, is should default to sameInstance instead of equalTo.

This would be a breaking change, not in the compile-time sense of the work, but in the semantical sense.
Something for Hamcrest 3.x.

The design of the Matcher API is not ideal:

• On the one hand, the Matcher interface is a prominent member of the API, and intuitively, users would implement it. But apparently that is not the intent. Code smell: Matcher._dont_implement_Matcher___instead_extend_BaseMatcher_.
• So users are supposed to extend BaseMatcher or a subclass thereof instead. What does it add? A toStringand describeMismatchimplementation, but neither are final so subclasses can override them - which would make them eligible to implement Matcher directly, but then they're not supposed to do that. It makes no sense - why have a Matcher interface then in the first place? The impression I get is that someone thought that "an interface looks better on the API than an abstract class".

The solution is to consolidate both in one abstract class.
Or, alternatively, an interface with default methods.

Now that Java source compatibility has been updated to 1.8 (on this fork), we are no longer restricted to Gradle 4.x, and we can finally update Gradle (and Checkstyle).

Whenever one implements Matcher, one has to implement at least two methods: matches(Object) and describeTo(Description description). It would be vastly more intuitive if there was a default implementation for the latter. Then one could implement a Matcher using a lambda. And usually, it's hard to come up with a good implementation of describeToanyway.

IntelliJ warns about the unused generic type parameter <T> on Matcher<T>. I think it can be removed without loss of functionality. It will cause less confusion.

Currently, Hamcrest's assertThat family of methods is defined on MatcherAssert.
It would be better to rename this to MatcherAssertions, to align with JUnit 5's Assertions which defines the assert family of methods.