Status for "most specific" varargs method?

Dan Smith daniel.smith at
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. "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> wrote:

> Hi,
> 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 :)
> thanks,
> Stephan
> 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 mailing list