public class Fibonacci {
�� �private static final int LENGTH = 7;
�� �public static void main(String[] args) {
�� � � �int[] fib = new int[LENGTH];
">

(original) (raw)

Joe,

I'm not sure I like this idea. �My one experience with forcing an array method to do double duty as varargs method was a disaster. �The method was Arrays.asList, and the result was Puzzler # 7 from "The Continuing Adventures of�Java�Puzzlers: Tiger Traps." �Here it is:


7\. �Fib O�Nacci�

public class Fibonacci {
�� �private static final int LENGTH = 7;
�� �public static void main(String\[\] args) {
�� � � �int\[\] fib = new int\[LENGTH\];
�� � � �fib\[0\] = fib\[1\] = 1; // First 2 Fibonacci numbers
�� � � �for (inti = 2; i < LENGTH; i++)
�� � � � � �fib\[i\] = fib\[i -2\] + fib\[i -1\];
�� � � �System.out.println(Arrays.asList(fib));
�� �}
}

The main moral of the puzzle was:

Use varargssparingly in your APIs
�� ��It can hide errors and cause confusion
�� ��This program wouldn't compile under 1.4

Arrays.hashCode, equals, and toString are already overloaded out the wazoo; adding varargs to the mix could be deadly. �Also, Arrays is not the place where people would go looking for what is essentially a hashing utility. �So I'm not in favor of varargifying the existing methods in Arrays, but I am in favor of adding a convenience method like this somewhere:

�� � � � /\*\*
�� � \* Generates a hash code for a sequence of input values. The hash code is
�� � \* generated as if all the input values were placed into an array, and that
�� � \* array were hashed by calling {@link Arrays#hashCode(Object\[\])}.
�� � \*

�� � \*

This method is useful for implementing {@link Object#hashCode()} on

�� � \* objects containing multiple fields. For example, if an object that has
�� � \* three �fields, {@code x}, {@code y}, and {@code z}, one could write:
�� � \* 
�� � \* @Override public int hashCode() {
  

�� � \* � � return Objects.hashCode(x, y, z);
�� � \* }
  

�� � \* 
�� � \* Warning: When a single object reference is supplied, the returned
  

�� � \* value does not equal the hash code of that object reference. This
�� � \* value can be computed by calling {@link #hashCode(Object)}.
  

�� � \*/
�� �public static int hash(Object... components) {
  

�� � � �return Arrays.hashCode(components);
�� �}
  


Viewed in isolation, it's simple, straightforward, and will help people write high quality hashCode methods. �I don't think Objects is a bad place for it, but you could put it is a "hash utility" class if we wrote such a thing.
  


�� � � � �Josh


On Thu, Oct 8, 2009 at 11:34 AM, Joseph D. Darcy <Joe.Darcy@sun.com> wrote:
  

  
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.
  

  
\-Joe