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

Paul Sandoz paul.sandoz at oracle.com
Fri Apr 26 06:27:45 PDT 2013

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#generalevolutionpolicy 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

More information about the lambda-dev mailing list