[Java] Consider using an alternative regular expression engine in Java to support all regular expressions used

[mrussek]

Is your feature request related to a problem? Please describe.
This is not a user-facing problem, but a problem facing developers of the Java version of this library.

The default Java regular expression engine does not support variable length negative lookbehind assertions. These assertions are commonly used in the specifications for many languages. The methods in RegExpUtility offer some mitigation, but they still do not handle the fact that the Java regex engine also does not support alternation in negative lookbehind assertions, as is required for Japanese number parsing for example. This makes parsing Japanese number parsing to Java effectively impossible.

Describe the solution you'd like
It would be possible to fix this issue by using a more fully featured regular expression engine, of which there are many available in Java. The branch at alternative_regex in my clone of the repository illustrates that we can use com.florianingerl.util.regex for example. That branch simply substitutes all instances of java.util.regex classes with the equivalent com.florianingerl.util.regex classes, and all tests are passing.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

There are other alternative regex engines available for Java.

1. Google's re2j library doesn't support variable length negative lookbehinds.
2. JRegex doesn't support variable length negative lookbehinds.

We could also continue to proceed without an alternative regex implementation, but it is unclear how to implement languages that require this functionality in Java.

[tellarin]

Thanks for looking into alternatives for a solution.
In principle, there is no problem with leveraging a different regex engine. The two main issues would be performance and maintainability.
Regarding perf, a simple benchmark replacing the current engine with the new one across all languages should provide enough evidence if the change has prohibitive cost.
Regarding maintainability, it all boils down to:

1. its license and
2. how feature complete the alternative is and how active its community is.

We don't want to bet on an engine that's going to be abandoned soon or won't have bug fixes. Wrapping the new engine and only using it where necessary help mitigate this to an extent.
License-wise, we took a look at the suggested engine repo and it lacks a clear license definition for it. I've opened an issue there about it. Let's see what they say.

[tellarin]

@mrussek, com.florianingerl.util.regex has added the missing license in their repo and it's MIT. Would you want to try to wrap it for the necessary Japanese cases? I'd recommend running the perf test mentioned above before that to make sure there's no major issue.

[mrussek]

I will look into wrapping it for only the required Japanese cases. I'll also try and execute the performance tests for a comparison.