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

[Stuart Marks]

On 2/11/15 12:45 PM, Paul Sandoz wrote:
> On Feb 11, 2015, at 8:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> That "matches" my original thinking on the matter and is reflected in the patch. It's very simple to support. If the method was named "findAll" then it would be misleading and imply a reset was needed.

OK, good, I see that, so it doesn't need to be changed.

> Ok, the first webrev i sent is already implemented as agreed so lets review that code.

I looked at:

 
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/

I think this was before you added Pattern.replaceFirst(), so that should be 
retrofitted here.

>>> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
>>
>> Why do you think we need a new sub-interface? Wouldn't it be sufficient to add default methods?
>
> What would the defaults do? Throwing an exception seems a poor solution to me.
>
> My guess it will be possible to evolve Matcher in binary and source compatible way to use the sub-type.

OK, I filed an RFE to cover this, then immediately closed it as a duplicate :-) 
because I failed to search for the existing RFE that covers this:

     https://bugs.openjdk.java.net/browse/JDK-8065554

Either we add some default methods that throw exceptions (gross) or we add a 
sub-interface (also gross). It might be a matter of taste, or bike shed 
painting. Either way, I think this needs to be done.

s'marks

>
> Paul.
>
>>
>> There is of course the possibility of existing 3rd party classes that implement MatchResult having conflicting methods. But I don't think MatchResult is implemented quite as often as the collection interfaces, where we've been reticent to add default methods because of so many implementations.
>>
>> I did a quick web search and I did find a few implementations/extensions of MatchResult, but there were no obvious conflicts. This isn't definitive, of course.
>>
>> The default implementations of group(String), start(String), and end(String) could throw IllegalArgumentException, since that's what the ones on Matcher do if there's no such named capture group.
>>
>> I admit this is a little weird, since it's only safe to use these new methods if you know where the MatchResult instance came from. So logically perhaps it's a different type. My hunch, though, is that MatchResults aren't passed around, they're created from Patterns/Matchers and processed within the same code, so in practice this won't be a problem.
>>
>> s'marks
>