When a developer uses an identifier that has the same name as a public class, such as {{Vector}}, a subsequent maintainer might be unaware that this identifier does not actually refer to {{java.util.Vector}} and might unintentionally use the custom {{Vector}} rather than the original {{java.util.Vector}} class. The custom type {{Vector}} can [shadow|BB. Glossary#shadow] a class name from {{java.util.Vector}}, as specified by the JLS, [§6.3.2, "Obscured Declarations"|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2] \[[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 of the _type-import-on-demand declaration_ (see the JLS, [§7.5.2, "Type-Import-on-Demand Declaration"|http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5.2] \[[JLS 2005|AA. Bibliography#JLS 05]\]) can complicate a programmer's attempt to determine which specific definition was intended to be used. Additionally, a common practice that can lead to errors 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 than the intended type in the Java include path, no further searches are conducted. Consequently, the wrong type is silently adopted. 

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");
    }
  }
}

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}}.