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

[Joseph D. Darcy]

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

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

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

Call site:

C.foo(42);

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
http://gbracha.blogspot.com/2009/09/systemic-overload.html

-Joe