Issue 172: optimize map hasKey() and hasEntry()

[brownian-motion]

Implements the enhancement in #172

Instead of a linear search over all entries, this change leverages Map.containsKey(K key) to check that a map hasKey() or hasEntry().

[nibsi]

I feel that the changes regarding visibility overshoot the scope of the issue, and warrant their own issue and pull request.

[brownian-motion]

Thank you for your feedback, @nibsi . I'm afraid I created the branch from my local master branch, which included a different change, instead of origin/master; I'm embarrassed I missed that before pushing. I'll rebase and push a PR without the unrelated change.

[nibsi]

You might want to add a unit test that checks that you can use the hasKey() and hasEntry() matchers with null keys even if the map implementation doesn't allow null keys, if it isn't there already. Otherwise, it looks good to me.

[brownian-motion]

I've added some tests that cover the relevant edge cases covered by the code addition. Thank you very much for your help, @nibsi! I believe this commit is ready for final review + merging if approved.

@tumbarumba , would you or a colleague in this repo please consider reviewing this PR when convenient?

[sf105]

Interesting question, the null thing is not something I thought of. The question is what is the right behaviour when using null with an inappropriate collection. Personally, I would have expected it to fail, rather than mismatch, as that's what would happen in the production code. I fear that we'll be hiding failure modes.

Also, is that a copy'n'paste in the comment?

[brownian-motion]

@sf105 There's one case I can think of where the safe API is better: asserting that a null key is absent:

assertThat(new Hashtable<Object, Object>(), not(hasKey(null)));

I would expect this to pass and continue to the next assertion; allowing a null pointer exception would force you to avoid touching particular types/code paths or start to put conditional logic and try/catches in your tests. Since it seems reasonable to assert that "this map type which prohibits null keys does not contain a null key", I support keeping this API that allows expressing that.

Also, sorry, where do you mean? I'm not sure what copy-and-paste you mean.

[brownian-motion]

@sf105 I would be happy to make whichever further changes you think would benefit the project the best. When convenient, please let me know what further adjustments might be appropriate here.

[nhojpatrick]

@brownian-motion looks good, please can you rebase from master, as hamcrest-core and hamcrest-library have been refactored a lot and also deprecated, so that everything is just in hamcrest.

[brownian-motion]

Hello again! I know it's been two years, but I've rebased this PR and would be happy to help with any further steps to get it ready for merging.

@nhojpatrick please feel free to look through this again when convenient :)

[nhojpatrick]

Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch v2.3-candidates.
Still trying to understand how has permissions to perform a release.