1

I have a dependency coexistence here: isNotNullValue() method exists in different jars in my Spring Boot application and this picture shows what I get for now:

enter image description here

As you can see, I have:

  • wiremock.org.hamcrest.core.IsNull
  • wiremock.org.hamcrest.CoreMatchers
  • org.hamcrest.core.IsNull
  • org.hamcrest.Matchers
  • org.hamcrest.CoreMatchers

Which one should I import?

I guess hamcrest-library is the right jar, but I am not sure.

Some guidelines to follow when:

  • same method exists simultaneously in several jars, while some should be shadowed but not(like in wiremock.org.hamcrest)
  • same method exists in several different jars of same dependency, as in hamcrest-core and hamcrest-library

?

WesternGun
  • 11,303
  • 6
  • 88
  • 157

1 Answers1

1

Among all the hamcrest suggestions, the one that I almost always end up using is from org.hamcrest.CoreMatchers. Both for isNull and is methods.

The reason you see a similar class hierarchy is because wiremock library has shaded a compatible version of hamcrest along with them. Sometimes you build a library that depends on specific version of dependencies but the users might have a different version of that library which may not be compatible with yours. While code might compile things might fail at Runtime while running them. This can happen with most widely used libraries like Guava (in elasticsearch), and in your case hamcrest (in wiremock). The solution to that problem is to shade the version of your dependencies along with a different package name so they don't cause conflicts or runtime issues for the users. The trade off is your artifact becomes slightly heavier since they also contain your dependencies.

Ashwanth Kumar
  • 667
  • 4
  • 10
  • Yes thanks. I know that `wiremock` may use his version of `hamcrest`, but they, as you say, can shade it and don't let me know. OK, so we have discarded `wiremock`, but another one is which jar to choose between `core-1.3` and `library-1.3`, and which between `CoreMatcher` and `Matcher`? Any reason for certain choice? – WesternGun May 12 '19 at 10:03
  • The "core" version of the hamcrest contains the basic set of matchers and abstract methods to build more matchers. The "library" version of hamcrest contains a lot more matchers implemented. `CoreMatchers` contains a smaller set of Matchers while the latter contains a lot more. I guess it mostly boils down to preference. For overlapping methods they're essentially the same thing. – Ashwanth Kumar May 12 '19 at 11:22
  • Oh I didn't know that. I guess I may go for the `library` jar. Thanks! – WesternGun May 12 '19 at 14:20