Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4420532

JLS2: Observability of a package is circularly defined

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P5 P5
    • 7, 8
    • 1.4.0
    • specification
    • 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."

            abuckley Alex Buckley
            gafter Neal Gafter (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: