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

[Joe Darcy]

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 gmail.com> 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

http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy

but the summary is:

> The general evolution policy for Java SE APIs implemented in OpenJDK is:
>
> 1.
>
>     Don't break binary compatibility
>     <http://cr.openjdk.java.net/%7Edarcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#binary_compatibility>
>     (as defined in the Java Language Specification
>     <http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.2>).
>
> 2.
>
>     Avoid introducing source incompatibilities
>     <http://cr.openjdk.java.net/%7Edarcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#source_compatibility>.
>
> 3.
>
>     Manage behavioral compatibility changes
>     <http://cr.openjdk.java.net/%7Edarcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#behavioral_compatibility>.
>

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

Cheers,

-Joe