-
Bug
-
Resolution: Fixed
-
P5
-
1.4.0
-
None
-
generic
-
solaris_7
-
Verified
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."
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."
- relates to
-
JDK-6470991 Package statement affected by imports
-
- Closed
-
-
JDK-6975015 7.5: Stricter prohibition against import from unnamed package
-
- Closed
-