Community
Participate
Working Groups
3.1 The compiler problem COMPILER_PB_VARARGS_ARGUMENT_NEED_CAST is a bit misleading, since it only explains one of two solutions to the underlying problem (see bug 103667) when it says: "Varargs argument null should be cast to Object[] when passed to the method addElements(Object...) from type VarargExample". The compiler preference page calls this 'Inexact type match for varargs argument', and I think the error message should rather explain this problem than propose a solution. My proposal for a more neutral error message: "Varargs argument null does not match argument type Object[] of method addElements(Object...) from type VarargExample".
Error message got improved during 3.2 cycle, it now reads: ---------- 1. WARNING in d:\eclipse\workspaces\dev3.2.1\plugins\Crap\src\X.java (at line 11) array(new Integer[] {5, 6}); //warns (as javac does) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The argument of type Integer[] should explicitly be cast to Serializable[] for the invocation of the varargs method array(Serializable...) from type X. It could alternatively be cast to Serializable for a varargs invocation ---------- 2. WARNING in d:\eclipse\workspaces\dev3.2.1\plugins\Crap\src\X.java (at line 12) array(null); //warns (as javac does) ^^^^^^^^^^^ The argument of type null should explicitly be cast to Serializable[] for the invocation of the varargs method array(Serializable...) from type X. It could alternatively be cast to Serializable for a varargs invocation ---------- on the following testcase import java.io.Serializable; import java.util.Arrays; public class X { static void array(Serializable... items) { System.out.print(Arrays.deepToString(items)); } @SuppressWarnings({"boxing"}) public static void main(String[] args) { array(new Serializable[] {3, 4}); array(new Integer[] {5, 6}); //warns (as javac does) array(null); //warns (as javac does) } }
Closing, pls reopen if you dislike the new message
See bug 103667 comment 6 why this got reopened.
Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=366617dbc4fc1d9363db17217a7ae199f0f005ea Regexes used to fix usages in test cases: Search: The argument of type ([\w\[\]]+) should explicitly be cast to ([\w\[\]]+) for the invocation of the varargs method (\w+)\(([^)]+)\) from type (\w+)\. It could alternatively be cast to ([\w\[\]]+) for a varargs invocation Replace: Type \1 of the last argument to method \3(\4) doesn't exactly match the vararg parameter type. Cast to \2 to confirm the non-varargs invocation, or pass individual arguments of type \6 for a varargs invocation. Search: The argument of type ([\w\[\]]+) should explicitly be cast to ([\w\[\]]+) for the invocation of the varargs constructor (\w+)\(([^)]+)\). It could alternatively be cast to ([\w\[\]]+) for a varargs invocation Replace: Type \1 of the last argument to constructor \3(\4) doesn't exactly match the vararg parameter type. Cast to \2 to confirm the non-varargs invocation, or pass individual arguments of type \5 for a varargs invocation.
I have this example: import java.io.Serializable; import java.util.Arrays; public class X { static void array(Serializable... items) { System.out.print(Arrays.deepToString(items)); } static void array(Object obj, Serializable... items) { System.out.print(Arrays.deepToString(items)); } static void array(Object obj1, Object obj2, Serializable... items) { System.out.print(Arrays.deepToString(items)); } public static void main(String[] args) { array(null, null); } } And it produces this warning: "Type null of the last argument to method array(Object, Serializable...) doesn't exactly match the vararg parameter type. Cast to Serializable[] to confirm the non-varargs invocation, or pass individual arguments of type Serializable for a varargs invocation." But the second suggestion doesn't make sense. In fact, it results in an error. I am wondering if we should just leave the suggestions out of the message and just report what the problem is.
I think the ecj warning needs some explanations, since this warning is not defined by the spec, cannot be disabled by the user, and is hard to understand. Not every Java developer is aware of the complicated three-phase method resolution process, and without any further explanation, the pure problem statement looks quite odd. The current wording not only proposes solutions, but it also implies the default behavior if the warning is not addressed, and it explains that this warning is about varargs vs. non-varargs invocations. This information is important to guide developers to the correct fix for their situation. The second suggestion ("pass individual arguments of type Serializable for a varargs invocation") does resolve the given problem, but that doesn't mean that this solution can't produce other problems. Your example is a nice test case, but that doesn't justify a less helpful warning message for the common case (non-overloaded varargs method). Of course, I'm open for improvements to the wording.
(In reply to Markus Keller from comment #6) > Of course, I'm open for improvements to the wording. Sorry, I don't have a better suggestion for the message without writing a full sentence for the error message :). I guess we can live with this unless someone complains about it. Verified for 4.4 M4 with build I20131209-2000.
Fixed CHKPII error with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=3743c4479cbac2ff6c8704e9f0a938a9ad18c145
