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

[Ulf Zibis]

Joe, much thank for your explanation. :-)

-Ulf


Am 09.10.2009 20:46, Joseph D. Darcy schrieb:
> 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
>
>