static class CharMatcher.NegatedFastMatcher extends CharMatcher.Negated
CharMatcher.FastMatcher
.CharMatcher.FastMatcher, CharMatcher.NamedFastMatcher, CharMatcher.NegatedFastMatcher, CharMatcher.Whitespace
original
Constructor and Description |
---|
NegatedFastMatcher(CharMatcher original) |
Modifier and Type | Method and Description |
---|---|
CharMatcher |
precomputed()
Returns a
char matcher functionally equivalent to this one, but which may be faster to
query than the original; your mileage may vary. |
countIn, matches, matchesAllOf, matchesNoneOf, negate, setBits, toString
and, any, anyOf, apply, ascii, breakingWhitespace, collapseFrom, digit, forPredicate, indexIn, indexIn, inRange, invisible, is, isNot, javaDigit, javaIsoControl, javaLetter, javaLetterOrDigit, javaLowerCase, javaUpperCase, lastIndexIn, matchesAnyOf, none, noneOf, or, precomputedInternal, removeFrom, replaceFrom, replaceFrom, retainFrom, singleWidth, trimAndCollapseFrom, trimFrom, trimLeadingFrom, trimTrailingFrom, whitespace
NegatedFastMatcher(CharMatcher original)
public final CharMatcher precomputed()
CharMatcher
char
matcher functionally equivalent to this one, but which may be faster to
query than the original; your mileage may vary. Precomputation takes time and is likely to be
worthwhile only if the precomputed matcher is queried many thousands of times.
This method has no effect (returns this
) when called in GWT: it's unclear whether a
precomputed matcher is faster, but it certainly consumes more memory, which doesn't seem like a
worthwhile tradeoff in a browser.
precomputed
in class CharMatcher