static class CharMatcher.NegatedFastMatcher extends CharMatcher.Negated
CharMatcher.FastMatcher.CharMatcher.FastMatcher, CharMatcher.NamedFastMatcher, CharMatcher.NegatedFastMatcher, CharMatcher.Whitespaceoriginal| 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, toStringand, 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, whitespaceNegatedFastMatcher(CharMatcher original)
public final CharMatcher precomputed()
CharMatcherchar 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