JDK-7042566 : Regression: new ambiguity between varargs method
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: unknown,x86
  • Submitted: 2011-05-06
  • Updated: 2014-02-11
  • Resolved: 2011-06-01
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
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
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) {
    }
}

Comments
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