Here is an alternative that pushes the methods on to Pattern instead: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
(Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.) I have also included replaceFirst. This simplifies things for streaming on the match results and also for replacing. Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me. Paul. On Feb 5, 2015, at 11:59 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi. > > Please review these stream/lambda enhancements on Matcher: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/ > > Two new methods are added to Matcher: > > 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the > existing replaceAll that accepts a single value. > > 2) Stream<MatchResult> results() that returns a stream of MatchResult for all > matches. > > The former does introduce a minor source incompatibility for a null argument, > but then so did the new append methods accepting StringBuilder that were > recently added (see JDK-8039124). > > For the latter i opted to place the method on Matcher rather than Pattern as > i think that is a better fit with current usages of Matcher and operating on > a MatchResult. That marginally increases the complexity since co-modification > checking is required. > > I update the test PatternStreamTest to derive the expected result. > > > I suppose i could add another method replaceFirst(Function<MatchResult, > String> ) if anyone feels strongly about that. Consistency-wise it seems the > right thing to do. > > Paul.
