Status for "most specific" varargs method?

[Dan Smith]

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.

—Dan

On Feb 11, 2014, at 9:18 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

> Hi,
> 
> Looking at remaining differences in behavior between javac and ecj,
> I came across this bug from 2009:
> 
>  https://bugs.openjdk.java.net/browse/JDK-6886431
> 
> 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 :)