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

[Paul Sandoz]

On Feb 27, 2015, at 7:18 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> 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".
> 

It's not really about casting a MatchResult to Matcher it's about the function capturing the Matcher instance and operating on it.


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

Can you suggest, via code, such a lighter weight immutable implementation?

If there was a lighter weight alternative we could apply that to replace* functions as well.

Paul.