Matcher.replaceAll(Function<MatchResult, String> f) [was: Re: hg: lambda/lambda/jdk: Pattern.splitAsStream.]
paul.sandoz at oracle.com
Fri Apr 26 06:27:45 PDT 2013
Hi Joe, Peter,
Thanks, this clears things up for me.
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.
>> 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:
>> 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.
More information about the lambda-dev