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.ma...@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.


Reply via email to