Matcher.replaceAll(Function<MatchResult, String> f) [was: Re: hg: lambda/lambda/jdk: Pattern.splitAsStream.]
joe.darcy at oracle.com
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 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