Page History

If a developer uses an identifier that reuses the name of 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 incorrectlyunintentionally use the custom {{Vector}} wheninstead their intention was to use 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 Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], [Section 6.3.2.|http://java.sun.com/docs/books/jls/third_edition/html/packages.html#6.3.2]. This can result causein unexpected program behavior.

Well-defined import statements can resolve these issues. However, when the definitions of the reused name definitions are imported from other packages, use of the _type-import-on-demand declaration_ (see \[[JLS 2005|AA. Bibliography#JLS 05]\], [Section 7.5.2|http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5.2], "Type-Import-on-Demand Declaration") can leadresult toin unexpectedimporting importan of aunintended class that was not intended. MoreoverAdditionally, 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.