For those of us with more experience it doesn't imply anything at all, because "blank" is such an ambiguous concept that any method in a library claiming to detect "blankness" is immediately banned for use by anyone who cares about what they're letting into their project.

My own Hamcrest cheat sheet marks them with skull marks for this reason:

In fact, "blank" does have a precise meaning in the Java ecosystem as I pointed out in my original post -- it should be consistent with the isBlank and isWhitespace methods of String and Character respectively.

I did learn from the associated PR that Hamcrest still supports older versions of Java that predate the String#isBlank convenience method; however, Character#isWhitespace has been present since 1.5 for Unicode code points and 1.1 for char values. I think it entirely appropriate that the IsBlank matcher be consistent with those results.

If you don't want to use the IsBlank matcher in your code, that's your decision, but it is a non-deprecated part of the Hamcrest library and as such I'd consider this a deficiency that can be fixed.

No, in the "Java ecosystem" you speak of, there are multiple definitions of whitespace. Just because you only know of one of them does not mean that the others do not exist.

Kevin Bourrillion compiled this spreadsheet:

https://docs.google.com/spreadsheets/d/1kq4ECwPjHX9B8QUCTPclgsDCXYaj7T-FlT4tB5q3ahk/edit#gid=0

You're right that it's a deficiency that can be fixed, but perhaps it should be fixed by removing the method.

Note that String.isBlank() was only introduced relatively recently in Java 11.
The Hamcrest sources predate that, and still build with Java 1.7 at the time of writing.

@peterdemaeyer understood, and I have updated the linked PR to remain compatible with that JDK.

I do think that since we're currently in rampdown for JDK16, that it's reasonable that devs will start using String#isBlank (I could have sworn this made it in in JDK8 for some reason -- guess JDK11 has been out even longer than I recalled at first) and make the same mistake.

As mentioned previously, Character#isWhitespace (which is what the convenience method ultimately boils down to using) dates back to 1.5, so I think it's reasonable that the implementation use that rather than the regex pattern \s (which I believe is ASCII-only to match PCRE and other older regex engines).