Bug ID: JDK-7042566 Regression: new ambiguity between varargs method

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7
7 b143Fixed

This was reported to NetBeans as bug:
http://netbeans.org/bugzilla/show_bug.cgi?id=198366

The problem is as follows. Consider code like this:
---------------------
public class Test {

    public static void t() {
        Exception ex = null;
        error("error", ex); //ambiguous error here
    }

    public static void error(Object object, Object... params) {
    }

    public static void error(Object object, Throwable t, Object... params) {
    }
}

SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a2d422d480cb

12-05-2011

EVALUATION This code should compile; the two potentially applicable methods are: m1 = error(Object, Object...) m2 = error(Object, Throwable, Object...) Now, is method m1 more specific than m2? No, because we have that: -Object <: Object (ok) -Object <: Throwable (no!) -Object <: Object (ok) Since the applicability test for the second argument fails, m1 is *not* more specific than m2. Is m2 more specific than m1? -Object <: Object (ok) -Throwable <: Object <: (ok!) -Object <: Object (ok) Since all applicability tests have succeeded, m2 is indeed more specific than m1. Since m2 is more specific than m1, but not vice-versa, m2 should be considered the most specific candidate. Javac performs the above steps by rewriting the signatures of the two varargs methods as follows: m1' = error(Object, Object, Object) m2' = error(Object, Throwable, Object) And then javac performs a straight applicability check between m1' and m2'; unfortunately, since the rewritten symbols for m1' and m2' still have the VARARGS flag set, javac will think that they are varargs methods, and this will make method applicability check fail (as the last argument type of both rewritten signatures is *not* an array, as javac would have expected). This problem has been partially fixed by 7013865 - but this particular instance of the problem has not been addressed. The solution is to remove the 'varargs' flag from the rewritten signature, and perform a simple applicability check (w/o varargs, i.e. 15.12.2.2 and 15.12.2.3 only). That will remove corner cases of varargs method resolution being applied to non-varargs methods.

06-05-2011

Duplicate :	JDK-7043984 - Compiler error
Relates :	JDK-6199075 - Unambiguous varargs method calls flagged as ambiguous
Relates :	JDK-7044388 - new varargs ambiguity error
Relates :	JDK-7013865 - varargs: javac crashes during overload resolution with generic varargs