On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shen<xueming.s...@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 "replacer" does not have an explicit reference to the matcher... and from the implementation it is not really about the "replacer" to change the state of the matcher, but the matcher's state gets changed during "replacing"? it might be more clear/obvious to move those warning notes up to the method doc as "the matcher state should not be updated/changed during the replaceAll is invoked..."? -sherman
