From http://www.ergnosis.com/java-spec-report/java-language/jls-7.4.3.html:

7.4.3 Observability of a Package

 7.4.3 Observability of a Package
 The definition of observable is circular

 The definition of the observability of a package introduced in
 the Second Edition of the JLS is circular.  In order to be
 observable, a package must be named in a package declaration; yet
 to be named in a package declaration, the package must be
 observable.  In essence, this arises because the package name
 which appears in a package declaration is processed, like any
 other package name, according to ��6.5.3 Meaning of Package Names.

 Let P be a top-level package.  According to ��7.4.3, P is
 observable iff P or one of its descendent packages is named in a
 package declaration in an observable compilation unit.  (The
 observable compilation units are implementation-defined.) 
 According to ��6.5.3.1 Simple Package Names, P must be in scope in
 order to be named.  Finally, according to ��7.4.4 Scope of a
 Package Declaration, P is in scope iff it is observable.  Thus,
 in order to be observable, P must be observable.  

 Similar reasoning applies to a subpackage Q.  Once again,
 according to ��7.4.3, Q is observable iff Q or one of its
 descendent packages is named in a package declaration in an
 observable compilation unit.  According to ��6.5.3.2 Qualified
 Package Names, Q must be an observable package in order to be
 named.  Thus, in order to be observable, Q must be observable.

 This confusion arises because it is unclear whether a package
 declaration (��7.4) in an observable compilation unit names a
 package, or ensures that a package exists and is observable.  If
 a package declaration is considered to name a package, then it is
 subject to the package name resolution rules of ��6.5.3 Meaning of
 Package Names, and the package it names must be observable
 (causing the cycle described above).  On the other hand, if a
 package declaration simply ensures that a package of that
 canonical name exists and is observable, then there is no cycle,
 and moreover a package declaration can never cause any of the
 compile-time errors described in ��6.5.3 because it names an
 unobservable package (since although it contains something which
 is syntactically a PackageName, that PackageName is not processed
 like a PackageName occuring in any other context).

 If this latter reading is the intended one, ��7.4.1 should state
 that the PackageName in a package declaration ensures that there
 is an observable package with the supplied canonical name, and
 that it is not subject to the rules in ��6.5.3 for determining the
 meaning of a package name.  Furthermore the first bullet of
 ��6.5.1 Syntactic Classification of a Name According to Context,
 which implies that package names in package declarations are
 indeed subject to ��6.5.3, must be removed.

 There is another solution, which fits more intuitively with
 existing practice and eliminates the clumsy and confusion notion
 of observability.  The JLS could simply say that which top-level
 packages exist, and their descendent packages, are
 implementation-defined, and that a package declaration is subject
 to the package name resolution rules in ��6.5.3, and thus must
 name a package which exists.  This approach allows the concept of
 package observability (depending somehow on compilation unit
 observability) to be dropped and replaced by a simpler notion of
 package existence, and does not require the PackageNames that
 occur package declarations to be treated any differently than
 other package names.

 In terms of the set of well-formed programs and the meaning of
 those programs, this latter approach is strictly equivalent to
 former one.  Whereas the latter formulation means that a package
 declaration can be ill-formed because it names a non-existent
 package, under the former rules an implementation is free to
 decide that any compilation unit which declares a package which
 the implementation is unable (or unwilling) to deem observable is
 itself unobservable.  In other words, for a given compilation
 unit, under the alternative approach an implementation might
 issue the error message "The named package does not exist." 
 Under the first approach, the error message might be "This
 compilation unit is not observable."