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

[Paul Sandoz]

Hi Joe, Peter,

Thanks, this clears things up for me.

Paul.

On Apr 24, 2013, at 10:45 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> 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:
>> 
>> Don't break binary compatibility (as defined in the Java Language Specification).
>> 
>> Avoid introducing source incompatibilities.
>> 
>> Manage behavioral compatibility changes.
>> 
> 
> So these kinds of source incompatibilities being discussed are not desirable, but they can be tolerable for a platform release.
> 
> Cheers,
> 
> -Joe