James Ring

As we describe in the [package documentation](https://github.com/google/re2j/blob/master/java/com/google/re2j/package.html), RE2/J implements the behavior specified by https://github.com/google/re2/wiki/Syntax. As noted on the github page, RE2J is not a drop-in replacement for `java.util.regex.Pattern` for this...

Are you able to share a code snippet demonstrating the problem? Also, maybe for your use case it's better to add all the strings to a `HashSet` and use `contains`.

Whether the Go License and the BSD3 license are substantially similar is beyond my pay grade. I'm sure this question has been raised before with the Go project itself. Maven...

RE2/J tries to implement [RE2's syntax](https://github.com/google/re2/wiki/Syntax), which specifies that `\b` match ASCII word boundaries only. I think this behavior is working as intended.

I was clear as to why I refused the PR: because it caused RE2J to differ from RE2 in behavior. It has nothing to do with making life more difficult...

Can you rebase your changes on top of the current master branch? It would be nice to see the benchmarks running in caliper.

- RE2J master [benchmarks](https://microbenchmarks.appspot.com/runs/6c99b83d-d648-4cab-872e-2e5d06a6b299#r:scenario.benchmarkSpec.methodName,scenario.benchmarkSpec.parameters.implementation) - https://github.com/Teradata/re2j/commit/6f63ede02c9356683f4f57de7054800f2051d518 [benchmarks](https://microbenchmarks.appspot.com/runs/04300898-80d4-4f09-aabf-8597c910539d#r:scenario.benchmarkSpec.methodName,scenario.benchmarkSpec.parameters.implementation)

Thank you for the fix, I'm working on reducing/removing the need for separate Unicode tables in RE2J. In the meantime, I'll cut a release with this fix.