j.ul.Objects follow-up: methods for var-argification?

Joseph D. Darcy Joe.Darcy at Sun.COM
Fri Oct 9 18:46:35 UTC 2009

Ulf Zibis wrote:
> Am 08.10.2009 20:34, Joseph D. Darcy schrieb:
>> Hello.
>> In the discussion about java.util.Objects, a few existing JDK methods 
>> were mentioned for possible var-argification:
>> java.util.Arrays.hashCode(Object[] a)
>> java.util.Arrays.deepHashCode(Object[] a)
>> java.util.Arrays.toString(Object[] a)
>> Also of possible general interest are some methods on String (bug 
>> 6762452 API change proposal: Enhance String constructor for varargs)
>> java.lang.String.copyValueOf(char[] data)
>> java.lang.String.valueOf(char[] data)
>> java.lang.String(char[] value)
>> Var-argification is fully binary compatible and is generally source 
>> compatible, although new conversions are allowed of course and 
>> overloadings may change.
> As String is final, there are no changed overloadings.
> As the Arrays methods are static, there are too no changed overloadings.

Being final and static alone are not enough to guarantee no new 
overloadings; although the overloading resolution rules are carefully 
crafted to try to select the same method if var-args is added to a class.

> OK, correct me, if I'm wrong.

FYI, here is a var-argification which breaks source compatibility:

Consider in final class C

static void foo(int..)
static void foo(Integer[])

static void foo(int...)
static void foo(Integer...)

Call site:


In the after scenario, both versions of foo *could* now be called and 
there is an ambiguity whereas before only the int... method could have 
been called.

For some interesting discussion of overloading, see


More information about the core-libs-dev mailing list