Skip to end of metadata
Go to start of metadata

The varargs feature was introduced in the JDK v1.5.0 to support methods that accept a variable numbers of arguments.

According to the Java SE 6 documentation [Sun 2006]:

As an API designer, you should use [varargs methods] sparingly, only when the benefit is truly compelling. Generally speaking, you should not overload a varargs method, or it will be difficult for programmers to figure out which overloading gets called.

Noncompliant Code Example

In this noncompliant code example, overloading varargs methods makes it unclear which definition of the doSomething() method is invoked.

class Varargs {
  private static void doSomething(boolean... bool) {
    System.out.print("Number of arguments: " + bool.length + ", Contents: ");

    for (boolean b : bool)
      System.out.print("[" + b + "]");
  } 
  private static void doSomething(boolean bool1, boolean bool2) {
    System.out.println("Overloaded method invoked");  
  }
  public static void main(String[] args) {
    doSomething(true, false);
  }
}

When run, this program outputs:

Overloaded method invoked

because the non-varargs definition is more specific and, consequently, a better fit for the arguments given. However, this complexity is best avoided.

Compliant Solution

To avoid overloading varargs methods, use distinct method names to ensure that the intended method is invoked, as shown in this compliant solution.

class Varargs {
  private static void doSomething1(boolean... bool) {
    System.out.print("Number of arguments: " + bool.length + ", Contents: ");

    for (boolean b : bool)
      System.out.print("[" + b + "]");
  } 
  private static void doSomething2(boolean bool1, boolean bool2) {
    System.out.println("Overloaded method invoked");  
  }
  public static void main(String[] args) {
    doSomething1(true, false);
  }
}

Exceptions

DCL08-EX1: It may be desirable to violate this guideline for performance reasons. One such reason would be to avoid the cost of creating an array instance and initializing it on every invocation of a method [Bloch 2008].

public void foo() { }
public void foo(int a1) { }
public void foo(int a1, int a2, int... rest) { }

When overloading varargs methods, it is important to avoid any ambiguity regarding which method would be invoked. This code sample avoids the possibility of incorrect method selection by using unambiguous method signatures.

Risk Assessment

Unmindful use of the varargs feature may create ambiguity and diminish code readability.

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

DCL08-J

low

unlikely

medium

P2

L3

Automated Detection

Automated detection is straightforward.

Bibliography

[Bloch 2008]

Item 42: "Use Varargs Judiciously"

[Steinberg 2005]

"Using the Varargs Language Feature"

[Sun 2006]

varargs


DCL64-J. Beware of integer literals beginning with 0      01. Declarations and Initialization (DCL)      

1 Comment

  1. As written, this guideline is nonnormative. The exception appears to be incorrect and only apply to a more stringently worded guideline.

    I think this guideline could be made normative with some slight rework, so I labeled it "maybe-normative"