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:
>> 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...)
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
For some interesting discussion of overloading, see
More information about the core-libs-dev