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. |
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).
ReturnType method(Object... args) { }
|
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.
<T> ReturnType method(T... args) { }
|
Be as specific as possible when declaring parameter types; avoid Object and imprecise generic types in varargs.
ReturnType method(SpecificObjectType... args) { }
|
Retrofitting old methods containing final array parameters with generically-typed varargs is not always a good idea. For example, given a method that does not accept an argument of a particular type, it could be possible to override the compile-time checking --- through the use of generic varargs parameters --- so that the method would compile cleanly rather than correctly, causing a compile-time error \[java:[Bloch 2008|AA. Bibliography#Bloch 08]\]. |
Also, note that autoboxing does not allow strong compile-time type checking of primitive types and their corresponding wrapper classes.
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.
Collection<T> assembleCollection(T... args) {
Collection<T> result = new HashSet<T>();
// add each argument to the result collection
return result;
}
|
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 appears to be straightforward.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="dc1d8b27-2d60-4046-bb10-95a98d92fc05"><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="c08c1929-e734-4db3-a977-23a35d6a7c6c"><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="8d0ba632-8ba0-4d02-b98b-e7d83964f18f"><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> |
DCL02-J. Avoid ambiguous overloading of varargs methods 01. Declarations and Initialization (DCL) DCL04-J. Do not derive a value associated with an enum from its ordinal