Bug 4027499 was incorectly closed as a duplicate of 4243915.
This bug documents its correct disposition. The original
description follows:

JLS says that a package and a class cannot have the same fully qualified
name, at least if the name is itself qualified. The compiler does not
always check for such a state of affairs. It should probably be more
thorough, looking for a package whenever it discovers a (non-nested) class.

Also, the compiler does not allow a class in the unnamed package to
have the same name as a top-level package. For example, a class with
a fully qualified name "kawa" cannot refer to other classes "kawa.lang.*".
I'm not sure if such a restriction can be read into JLS, but I think it's
desirable, since an import in a null package containing "kawa" of "kawa.lang"
necessarily refers to a nested class "lang", since class names take precedence
over package names. This means that the package "kawa", even if it is legal,
is completely hidden. Much better to make it illegal, by analogy with members
of named packages.

(Currently, javac checks for package/class ambiguity on "import X.*" statements,
and when a type name "X.Y" fails to resolve and "X" is a class.)

The new class nesting rules work much better if the restriction against
ambiguity is enforced. If "X" is both a class and a package, and the
class "X" has no member "Y" but the package "X" has a class member "Y",
the name "X.Y" will fail to resolve, because "X" is taken to be a class
not a package. It is important to report the package/class ambiguity
in this case.