Matcher.replaceAll(Function<MatchResult, String> f) [was: Re: hg: lambda/lambda/jdk: Pattern.splitAsStream.]

Joe Darcy joe.darcy at
Wed Apr 24 13:45:49 PDT 2013

On 04/23/2013 12:00 AM, Peter Levart wrote:
> On 04/22/2013 04:24 PM, Paul Sandoz wrote:
>> On Apr 22, 2013, at 4:11 PM, Peter Levart <peter.levart at> wrote:
>>> On 04/22/2013 02:54 PM, Paul Sandoz wrote:
>>>> Hi Jürgen,
>>>> Three issues:
>>>> - we should probably include replaceFirst
>>>> - we need to use different method names since replaceAll(null) is now ambiguous
>>> But only if used with literal 'null' and then it throws NPE if the match is found, so I doubt anyone is using "matcher.replaceAll(null)" as a shorthand for "if (matcher.find()) throw new NullPointerException()" in disguise...
>> I hope not too :-) Note that such a change does result in a compilation failure for the regex tests.
>> I don't quite know what the source code level compatibility requirements are here. How high is the bar set? I was presuming it was quite high.
>> Paul.
> This is a kind of source-level incompatibility where there is a simple
> fix which makes code compilable also with previous major versions of JDK
> (very important!). In addition it is very unlikely that such usage is
> found in real-world code (the test is specific in this respect, since it
> exhibits corner cases). Considering that when some code-base wants to
> migrate to JDK8, there will be other places where fixes are going to be
> necessary because of source-level incompatibilities with generics,
> inference, etc., this very unlikely incompatibility will be taken care
> of in the same batch.
> It would be a waste not to re-use the most natural choice of method name
> in this case, I think.

Just a general comment on the JDK compatibly policy, there is a long 
discussion of compatibly in

but the summary is:

> The general evolution policy for Java SE APIs implemented in OpenJDK is:
> 1.
>     Don't break binary compatibility
>     <>
>     (as defined in the Java Language Specification
>     <>).
> 2.
>     Avoid introducing source incompatibilities
>     <>.
> 3.
>     Manage behavioral compatibility changes
>     <>.

So these kinds of source incompatibilities being discussed are not 
desirable, but they can be tolerable for a platform release.



More information about the lambda-dev mailing list