j.ul.Objects follow-up: methods for var-argification?
Ulf.Zibis at gmx.de
Fri Oct 9 21:19:51 UTC 2009
Joe, much thank for your explanation. :-)
Am 09.10.2009 20:46, Joseph D. Darcy schrieb:
> 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...)
> 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