Bool is a project that uses Hamcrest matchers to provide a clean way to write conditionals and making them readable even for your clients.
Note that apart from cleaning your code, it forces you to maintain the level of abstraction of methods without having to populate your classes with a list of methods that are composed by one line returning a boolean value like next example:
Hamcrest it is not a testing library: it just happens that matchers are very useful for testing.
Hamcrest is used in many projects, JUnit for asserting tests (most of us have use it in this way), or Mockito. But as previous cite said,Hamcrest can be also used outside testing scope, Lambdaj is an example, and Bool is another one.
Bool is also useful when you are dealing with collections. Because you can use any matcher from Hamcrest project you can implement conditions that would require some work if you didn't use Bool, in a few seconds; see next example:
But also with arrays are improved so much, when you want to compare two arrays you cannot do by using equals method directly but using Arrays.equals method. But Hamcrest matchers deals with this problem, hiding this details from developers so we can compare arrays safely.
And of course you can use all matchers you can imagine like contains, empty, containsInAnyOrder, ...
Let's complicate things a bit more.
Normally, our conditions contain more than one clause. For example, the name should be "Alex" or "Ada".
For covering this case, be and is keyword is also available. is keyword provides a better readability to your conditions, but can conflict with Hamcrest "is" method. So be is also provided. You can use any of them.
It seems reasonable that using Bool performance should be worst than using native conditions. But I have to say that I have been pleasantly surprised by the performance of Bool and Hamcrest matchers.
I have run 5000 times some examples provided in documentation. For example one single condition, one condition negated, two conditions over the same attribute with and keyword, two attributes being compared with one condition, and finally one collection comparison. And the results are the next ones:
Note that using simple conditions the time is the same, and is after we start creating more complex condition expressions that the performance is a bit reduced.
You can find the performance test in com.lordofthejars.bool.performance.PerformanceTests
Please keep in mind that the border between writing clean and readable code and something unintelligible is very thin. You can start creating a complex chaining of calls, train wreck, so no one can understand the real meaning of the condition.
One good practice to avoid this case is splitting complex chaining calls into multiple variables and then the final calls are executed inside the if (or inside a method which extracts all this logic). But anyway if you found creating a really complex condition, think about the correctness of this logic before coding it, because maybe you are providing to a condition a heavy responsibility.
Also note that you can use Bool in all of your conditions, but where you really take the full power is in conditions that represents important rules for your business.