RFR 8071479: Stream and lamdification improvements to j.u.regex.Matcher
Stuart Marks
stuart.marks at oracle.com
Fri Feb 27 23:19:57 UTC 2015
On 2/27/15 12:40 PM, Xueming Shen wrote:
> On 02/27/2015 11:21 AM, Xueming Shen wrote:
>> On 02/27/2015 10:55 AM, Paul Sandoz wrote:
>>>
>>> What about a light wright immutable MatchResult? is that possible?
>>
>> Should be possible. I can give it try.
>
> too repetitive?
>
> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
Not too bad. I know I was surprised to see that Matcher itself is the only
MatchResult implementation, and that there wasn't a lightweight immutable
MatchResult separate from Matcher. So I'm glad to see this added.
(One thing to think about, not part of this particular change, is whether named
matching groups could be added to or extend MatchResult. Doing that would change
the implementation of the lightweight MatchResult. See JDK-8065554.)
A few comments on the implementation.
At line 302, end(group) calls the groupCount() method instead of returning the
captured groupCount local.
The MatchResult anonymous class unavoidably captures a reference to 'this',
which is the enclosing Matcher instance. I don't think it needs that, but it
does enable methods like groupCount() on the enclosing class to be called
inadvertently.
For these reasons the lightweight MatchResult might better be refactored to be a
(named) static nested class (or even a top-level class). You'll have to write a
constructor and declare fields instead of capturing locals though, but I think
this makes it a bit more clear as to what's actually going on. For example, you
could make all the fields final to make it clear that the object really is
immutable.
s'marks
More information about the core-libs-dev
mailing list