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

[Xueming Shen]

Hi Paul,

1133      * @param  replacer
1134      *         The function to be applied to the match result of this matcher
1135      *         that returns a replacement string.
1136      *
1137      *<p>  The function should not modify this matcher's state during
1138      *         replacement.  This method will, on a best-effort basis, throw a
1139      *         {@link java.util.ConcurrentModificationException} if such
1140      *         modification is detected.
1141      *
1142      *<p>  The state of the match result is guaranteed to be constant
1143      *         only for the duration of the function call and only if the
1144      *         function does not modify this matcher's state.


1151      * @throws ConcurrentModificationException if it is detected, on a
1152      *         best-effort basis, that the replacer function modified this
1153      *         matcher's state


Just wonder from API point of view, in theory the replacer should not be able to modify
this matcher's state via a MatchResult, it is the side-effect of our implementation detail
that happens to return "this matcher" as a MatchResult. For example, it should be possible
to simply return a wrapper MatchResult on top of this matcher to only expose the read-only
MatchResult methods, so the "replacer" will never be possible to modify the "matcher".

The modCount might still be good to have to catch the possible concurrent modification
of the "matcher" while iterating, though the existing implementation does not do that for
the original methods

The "results" currently returns "heavy" clone of this matcher, it might be ideal
to have a light weight MatchResult implementation with less fields and especially
to a single "text.toString()", this might be helpful when the "text" is huge and it
is not a "String" object.

-Sherman

On 02/27/2015 08:32 AM, Paul Sandoz wrote:
> Hi,
>
> On Feb 13, 2015, at 8:26 PM, Stuart Marks<stuart.marks at oracle.com>  wrote:
>> OK, this looks great. Thanks for the updates.
>>
>> There is also
>>
>>     "in same order" ->  "in the same order"
>>
>> in the doc for the results() method, as Brian pointed out internally.
>>
>> No need for another webrev.
>>
> Alas there is :-) I made some updates:
>
> 1) Improving the documentation based on feedback from Brian; and
>
> 2) added co-mod checking to the replace* methods.
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev
>
> Paul.
>