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
