Do not reuse the names of publicly-visible identifiers, public utility classes, interfaces, or packages in the Java Standard Library.
When a developer uses an identifier that has the same name as a public class, such as {{Vector}}, a subsequent maintainer might not be aware that this identifier does not actually refer to {{java.util.Vector}}, and might unintentionally use the custom {{Vector}} instead of the original {{java.util.Vector}} class. The custom type {{Vector}} can [shadow|BB. Definitions#shadow] a class name from {{java.util.Vector}}, as specified by [§6.3.2|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2] of the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\]. This can result in unexpected program behavior. |
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. |
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.
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"); } } } |
This compliant solution uses a different name for the class, preventing any potential shadowing of the class from the Java Standard Library.
class MyVector { //other code } |
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}}. |
Public identifier reuse decreases the readability and maintainability of code.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
DCL01-J |
low |
unlikely |
medium |
P2 |
L3 |
An automated tool can easily detect reuse of the set of names representing public classes or interfaces from the Java Standard Library.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b656566f-f98c-43cf-b154-92861278c63d"><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="3dcb72e1-e037-4e97-a014-e809e84e30b9"><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="687f8b47-2849-4bcf-9bfd-9e99f87a160a"><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="e2a35347-8a16-4839-9291-49dec431c8c5"><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> |
01. Declarations and Initialization (DCL) DCL02-J. Avoid ambiguous overloading of varargs methods