Added support for reverse variable matching

[nrktkt]

Addresses #2

Bumped Java version to 8

• Named capture groups not supported in 6
• I like to lambda

Added Either monad class to deal with repeated variables.

Currently this should support the majority of use cases, however more work can be done to better support level 4 templates.

Future work:

• Make matchParameters and matchSegments inspect each VarSpec for allowed characters
• Make matchParameters and matchSegments inspect each VarSpec for explode modifier
  • Currently multiple parameters will automatically become a list, regardless of presence of explode
  • Currently multiple segments are not supported
• Make buildMatchingPattern match more strictly, seems to work OK now but could result in issue reports later
• Integrate with existing test suites and generally expand testing.

[damnhandy]

Thanks!

[jroper]

In order to get reasonable performance, this pattern will need to be precompiled so it can be used over and over.

[nrktkt]

quite right, this and the pattern in matchParameters should be compiled late and once.

[jroper]

Any reason for limiting this to 9001 characters? You can use .+ if you want to match at least one character.

[nrktkt]

Yes, there was an issue with unbounded match. It would cause a stack overflow IIRC. 9001 is sufficiently large for a single sane expression, and investigating and documenting the phenomenon more is intended to fall under the todo.

[jroper]

SecureRandom is a very expensive way to generate random names, in particular it's blocking, only one thread can generate a name at a time, and depending on your JVM configuration, it can block indefinitely if your system has no entropy. If the aim is to ensure that each name this class generates is unique within the scope of this class, then I'd just use an AtomicLong, and generate names like var1, var2, var3 using incrementAndGet. This is fast, non blocking, and guarantees uniqueness up to Long.MAX_VALUE names (technically there's no such guarantee with SecureRandom).

[nrktkt]

A good point. My original thought was that the collision chance of 12 bytes was practically none, and a counter could max out on a long running server.
Now that you bring it up however, I think the performance hit of random is greater than the practical likelihood of using over 8 bytes of expressions (and if it becomes an issue, later code could handle it by resetting the counter or creating new counters and appending them together as strings).