...
A simple name may occur in contexts where it may potentially be interpreted as the name of a variable, a type or a package. In these situations, the rules of §6§6.5 specify that a variable will be chosen in preference to a type, and that a type will be chosen in preference to a package.
Thus As a result a variable can obscure a type or a package and a type can obscure a package name. Shadowing on the other hand refers to masking of variables, fields, types, method parameters, labels and exception handler parameters in a subscope. Both these differ from hiding wherein a member that should have been inherited by a subclass is forgone in lieu of a locally declared subclass member, that assumes the same name.
...
This noncompliant example implements a class that reuses the name of the class java.util.Vector. The intent of this class is to introduce a different condition for the isEmpty method for interfacing with native legacy code. A future programmer may not know about this extension and may incorrectly use the Vector idiom to use the original java.util.Vector class, by adding an import statement. Since a type (Vector class) can obscure a package name (java.util.Vector), the custom class Vector defined in the same package as VectorUser takes precedence, thus as a result causing undesirable effects as a direct consequence of violating the programmer's assumptions.
...
Note that class y.C is accessible from the package x and so is its doLogic() method. If however, the main() method defined in class A tries to polymorphically invoke y.doLogic() as shown, the override corresponding to class B in package x will take precedence. This is because the doLogic() methods in classes x.A and x.B are not visible from class y.C due to the default access specifier. Thus As a result the class x.C is not considered a part of the overriding hierarchy. Notably, the code behaves as expected if the access specifiers of all the methods are changed to public.
...