...
| Wiki Markup |
|---|
Well-defined import statements can resolve these issues. However, when reused name definitions are imported from other packages, use the _type-import-on-demand declaration_ (see [§7.5.2, "Type-Import-on-Demand Declaration"|http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5.2] of the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\]). Additionally, a common, and potentially misleading, tendency is to produce the import statements _after_ writing the code, often via automatic inclusion of import statements by an IDE. This creates further ambiguity with respect to the names; when a custom type is found earlier in the Java include path than the intended type, no further searches are conducted. |
Noncompliant Code Example (Class Name)
This noncompliant code example implements a class that reuses the name of the class java.util.Vector. It attempts to introduce a different condition for the isEmpty() method for interfacing with native legacy code by overriding the corresponding method in java.util.Vector. Unexpected behavior can arise if a maintainer confuses the isEmpty() method with java.util.Vector.isEmpty() method.
| Code Block | ||
|---|---|---|
| ||
class Vector {
private int val = 1;
public boolean isEmpty() {
if (val == 1) { // compares with 1 instead of 0
return true;
} else {
return false;
}
}
// other functionality is same as java.util.Vector
}
// import java.util.Vector; omitted
public class VectorUser {
public static void main(String[] args) {
Vector v = new Vector();
if (v.isEmpty()) {
System.out.println("Vector is empty");
}
}
}
|
Compliant Solution (Class Name)
This compliant solution uses a different name for the class, preventing any potential shadowing.
...
| Wiki Markup |
|---|
When the developer and organization control the original shadowed class, it may be preferable to change the design strategy of the original in accordance with Bloch's _Effective Java_ \[[Bloch 2008|AA. Bibliography#Bloch 08]\] "Item 16: Prefer interfaces to abstract classes." Changing the original class into an interface would permit class {{MyVector}} to declare that it implements the hypothetical {{Vector}} interface. This would permit client code that intended to use {{MyVector}} to remain compatible with code that uses the original implementation of {{Vector}}. |
Risk Assessment
Name reuse decreases the readability and maintainability of code.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
DCL16DCL05-J | low | unlikely | medium | P2 | L3 |
Automated Detection
An automated tool can easily detect reuse of the set of names representing public classes or interfaces from the Java Standard Library.
Related Guidelines
C Secure Coding Standard: "PRE04-C. Do not reuse a standard header file name"
C++ Secure Coding Standard: "PRE04-CPP. Do not reuse a standard header file name"
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="66e384e4b18284a9-1f4dc1e1-4ce240db-9862a58e-425667e137a4b31c95e027ff"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | [§6.3.2, "Obscured Declarations" | http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2] | ]]></ac:plain-text-body></ac:structured-macro> |
| |||||
| |||||
| |||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="400f81b3f66df0e3-464464a9-4b8540b9-8a16975e-79b89148513e59fb128b76f5"><ac:plain-text-body><![CDATA[ | [[FindBugs 2008 | AA. Bibliography#FindBugs 08]] | ]]></ac:plain-text-body></ac:structured-macro> | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="668a2c40fbb39582-3476b98b-4e83437f-8c3a8281-7df9808ec4c31e4735820983"><ac:plain-text-body><![CDATA[ | [[Bloch 2005 | AA. Bibliography#Bloch 05]] | Puzzle 67: All Strung Out | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="31fb8b8ffa8ad051-76f27784-4b4c4d18-bc74a4d0-52c59573077671e8197c537a"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 16: Prefer interfaces to abstract classes | ]]></ac:plain-text-body></ac:structured-macro> |
...