Deprecate methods with same name as in org.hamcrest.Matchers

[runeflobakk]

A slight annoyance when I use java-8-matchers is that quite often I also use matchers from org.hamcrest.Matchers. As I use static imports for matchers to make asserts easier to read, there will often be name clashes with matchers from Hamcrest, and I have to choose which one I want to static import.

For example, in a test class asserting both streams and lists being empty:

import static org.hamcrest.Matchers.empty;
import uk.co.probablyfine.matchers.StreamMatchers;
...
assertThat(myList, empty());   // easy on the eye
...
assertThat(myStream, StreamMatchers.empty());   // ugh...

Since there is a 2.0 release coming up, how would you feel about deprecating the methods in StreamMatchers and OptionalMatchers having same names as methods in org.hamcrest.Matchers, and introduce new methods for the ones being deprecated? For instance, in the case of StreamMatchers.empty(), this could be solved with something like this:

public class StreamMatchers {

    public static <T,S extends BaseStream<T,? extends S>> Matcher<S> emptyStream() {
        // existing implementation
    }

    /**
     * @deprecated Use {@link StreamMatchers#emptyStream()} instead.
     */
    @Deprecated
    public static <T,S extends BaseStream<T,? extends S>> Matcher<S> empty() {
        return StreamMatchers.emptyStream();
    }

    ...

}

Other candidates include:

• StreamMatchers.equalTo
• StreamMatchers.startsWith
• OptionalMatchers.empty
• OptionalMatchers.contains

Other methods, which does not necessarily clash with methods in org.hamcrest.Matchers may also need to be renamed (deprecated, and new method introduced) to be consistent with new names, e.g. OptionalMatchers.emptyInt().

I can prepare such a pull-request, but I wanted to run this by you first to have your thoughts on the matter. A new major release presents an opportunity to revise the parts of the API which maybe should be changed.

As #5 is really just about internals, it is not necessary to do a release immediately after merging it. One possibility is to introduce a v2-branch or something, which functions as the mainline-branch for an upcoming 2.0.0-release, and eventually merge that one into the master branch when actually releasing v2.0.0.