Status for "most specific" varargs method?
daniel.smith at oracle.com
Tue Feb 11 10:37:52 PST 2014
This problem was fixed in JDK 7 and mentioned in the release notes, even though this particular bug was not closed.
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#jdk7 "Changes in Most Specific Varargs Method Selection"
So I've closed the bug.
We toyed with some ideas for enhancing most-specific to allow things like this in 8, but there was a lot of redundancy with the staged approach to boxing currently used by JLS, and we weren't confident enough to dump the staged approach, so ultimately rolled most-specific back to only give special treatment to functional interfaces (this was spec version 0.6.3). I'm surprised to see some of this work apparently leaking through into javac; I'll report a new bug.
On Feb 11, 2014, at 9:18 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
> Looking at remaining differences in behavior between javac and ecj,
> I came across this bug from 2009:
> This made me wonder about the status of this bug.
> * Is JLS8 supposed to change the picture?
> - (I don't see it would)
> * Are there plans to fix this in javac?
> - (javac8 again shows the bug, after javac7 did not)
> We'd love to be consistent with JLS *and* javac :)
> PS: I made experiments as to what spec changes would allow us
> to accept the example. I figured extending the 3 phases of
> overload resolution into 4 might be the cleanest way:
> 1. applicable by strict invocation
> 2. applicable by loose invocation
> 3. applicable by variable-arity strict invocation
> 4. applicable by variable-arity loose invocation
> IFF the current javac behavior is desired, then this would be
> my proposal for JLS9 :)
More information about the lambda-spec-experts