DCL08-J. Enforce compile-time type checking of variable argument types

The Java compiler type-checks the arguments to a varargs method to ensure that they are of the same type or object reference. However, the compile-time checking is ineffective when two method signatures are used in particular - Object and the generic type T [[Bloch 08]].

Another requirement for providing strong compile-time type checking of variable argument methods is to be as specific as possible when declaring the type of the method parameter.

Noncompliant Code Example

This noncompliant code example declares two methods, one with an Object parameter and another with a generic type T. Both these approaches are flawed as they break string compile-time type checking.

ReturnType1 suspect1(Object... args) { }
<T> ReturnType2 suspect2(T... args) { }

Compliant Solution

Do not use generic types like Object in varargs and be as specific as possible when declaring parameter types.

ReturnType1 specific1(primitiveType1... args) { }
ReturnType2 specific2(primitiveType2... args) { }

Noncompliant Code Example

This noncompliant code example shows autoboxing in action when the doSomething method is called with the primitive integer 1 as a parameter (converted to Integer type).

doSomething(1)

private void doSomething(Integer... i) {
  System.out.println("autoboxed");
}

Compliant Solution

Be as specific as possible while defining the type of a varargs method to enforce strong compile-time checking.

doSomething(1)

private void doSomething(int... i) { // use int instead of Integer here
  System.out.println("specific");
}

Retrofitting old methods containing final array parameters with generically typed varargs is not always a good idea. This is because if some method did not accept an argument of a particular type, it may be possible to override the compile-time checking so that with the use of generic varargs, it now compiles cleanly. [[Bloch 08]]

Risk Assessment

Unmindful use of the varargs feature breaks strong compile-time type checking, may create ambiguity and diminish code readability.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[Sun 06]] varargs
[[Bloch 08]] Item 42: "Use varargs judiciously"
[[Steinberg 05]] "Using the Varargs Language Feature"

DCL07-J. Ensure failure atomicity by declaring class and instance variables final and initializing immediately      02. Declarations and Initialization (DCL)      DCL30-J. Do not attempt to assign to the loop variable in an enhanced for loop