RFR 8071479: Stream and lamdification improvements to j.u.regex.Matcher

[Paul Sandoz]

On Mar 3, 2015, at 3:09 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 3/2/15 1:49 AM, Paul Sandoz wrote:
>> On Feb 28, 2015, at 4:40 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
>>> Updated to a static private class for the toMatchResult(). Added a private field MatchResult for the anonymous MatchResult
>>> wrapper.
>>> 
>>> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>>> 
>> 
>> Many thanks, i took most of that code and updated:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>> 
>> - additional documentation for replacer function parameter is moved to the main body
>> 
>> - there is no need for an internal MatchResult instance wrapper. It does not protect against state modification, does not protect against escape, creates another object for all matcher instances, and results in more wrapping. The only way we can avoid the first 2 is by using an immutable match result, which has it's own cost that unfortunately we cannot avoid in the results().
> 
> 
> Even though there's more overhead, I like the idea of creating a distinct match result for each stream value. Consider what might happen if somebody decided to collect the match results into a list at the end of the pipeline.

Right, we cannot avoid it (sequentially or for parallel).


> (Did the earlier versions pass "this" down the stream?

No.


> If so, boy, was that a latent bug.)


> I'm reminded of one of the old Map entrySet iterators that reused the same Map.Entry instance for the duration of the iteration. That caused some problems.
> 

See ServiceLoader :-)


> Anyway, this latest version looks fine.
> 

Thanks!
Paul.