Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Wiki Markup
            The Java compiler type checks the arguments to each varargs method to ensure that the arguments are of the same type or object reference. However, the compile-time checking is ineffective when {{Object}} or generic {{T}} parameter types are used \[java:[Bloch 2008|AA. Bibliography#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 (Object)

This noncompliant code example declares a vararg method using Object. It accepts an arbitrary mix of parameters of any object type. Legitimate uses of such declarations are rare. (See exception below).

Code Block
bgColor#FFCCCC
ReturnType method(Object... args) { }

Noncompliant Code Example (Generic Type)

This noncompliant code example declares a vararg method using a generic type parameter. It accepts a variable number of parameters that are all of the same object type. Again, legitimate uses of such declarations are rare.

Code Block
bgColor#FFCCCC
<T> ReturnType method(T... args) { }

Compliant Solution

Be as specific as possible when declaring parameter types; avoid Object and imprecise generic types in varargs.

...

Also, note that autoboxing does not allow strong compile-time type checking of primitive types and their corresponding wrapper classes.

Exceptions

DCL03-EX0: Varargs signatures using Object and imprecise generic types are acceptable when the body of the method does not use casts or auto-boxing and compiles without error. Consider the following example, which operates correctly for all object types and type checks successfully.

Code Block
bgColor#ccccff
Collection<T> assembleCollection(T... args) {
  Collection<T> result = new HashSet<T>();
  // add each argument to the result collection
  return result;
}

Risk Assessment

Unmindful use of the varargs feature prevents strong compile-time type checking, creates ambiguity, and diminishes code readability.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

DCL03-J

low

unlikely

medium

P2

L3

Automated Detection

Automated detection appears to be straightforward.

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4c177a5d91337855-214b2c61-48274af8-9e8c8f61-02e080f276a0b3b6648323bb"><ac:plain-text-body><![CDATA[

[java:[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 42: "Use Varargs Judiciously"

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="da7e6165e79a2425-db10ab64-499546d5-a49b9c4f-99f7cd8d716549c63999ae83"><ac:plain-text-body><![CDATA[

[java:[Steinberg 2005

AA. Bibliography#Steinberg 05]]

"Using the Varargs Language Feature"

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a25ff3e4f06089fd-38ca4ee5-4618491c-9fe4bf05-30162f06c25de35f4cf8d903"><ac:plain-text-body><![CDATA[

[java:[Sun 2006

AA. Bibliography#Sun 06]]

[varargs

http://java.sun.com/j2se/1.5.0/docs/guide/language/varargs.html]

]]></ac:plain-text-body></ac:structured-macro>

...