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

# Need improved diagnostics for misplaced source files and ill-formed classpath

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • 1.1, 1.1.1, 1.1.5, 1.2.0, 1.2.2, 1.3.0
    • tools
    • generic, x86, sparc
    • generic, solaris_2.5.1, windows_95, windows_nt

      Both the old 'javac' in JDK 1.2 and the new one in JDK 1.3 behave in a
      confusing manner when the fully-qualified name of a class as determined
      by its name and the package declaration in its compilation unit do not
      agree with the placement of its source file as specified in JLS 7.2.1.

      The following improvements should be made:

      1. When searching for a source file on the sourcepath or classpath,
      we should verify that the file that we found contains the correct
      class. If not, we should report a diagnostic and *continue searching*.
      Presently, the JDK1.2 compiler reports a diagnostic, but stops the search.
      The new JDK1.3 compiler fails to find the desired class without further
      comment.
      (See 4019348.)

      2. When compiling a source file specified on the command line, we may
      wish to verify that the location of the file relative to the prevailing
      sourcepath is correct. Users currently rely, however, on the fact that
      the compiler does not require this. It is common to compile a collection
      of java source files stored at the same level in the directory hiearchy
      using -d to correctly place the resulting class files. This works fine
      as long as we compile all the files at once, so that the sourcepath is
      never searched. We might choose to deprecate this practice and always
      issue a warning when a source file is 'out of place', or provide a switch
      to control the compiler's behavior.
      (See 4257856 and 4032273.)

      In the evaluation of bug 4032273, we referred to the technical difficulty
      of determining whether a file specified on the command line was the same
      as one encountered during a serach of the sourcepath. In fact, it should
      suffice to query the absolute path names of the sourcefile as found on the
      command-line and as found on the classpath.

      Bug 4303048 proposes an overhaul of the compiler command-line semantics,
      which would be a good occasion to make such a change.

      3. Certain classpaths are simply ill-formed, for example, they are
      self-overlapping (".:..") and can thus cause a directory representing
      a package and a file representing a class to appear spuriously at the
      same level within the induced package namespace hierarchy. Similarly,
      the requirement that the placement of the source files agree with their
      declared package is not consistently enforced across the entire classpath.
      In general, such enforcement is not desired, even if it were not horrendously
      inefficient, as it would prohibit us from compiling a set of related files
      while another such set, completely independent of the first, was in an
      inconsistent state (e.g., under development). It would be nice, however,
      if the compiler could, upon request, validate the entire sourcepath and
      classpath and the correct placement of the files contained therein.
      I propose a '-validate' switch that would force a complete validation
      prior to compiling the (possibly empty) list of source files.
      (See 4227952.)

      william.maddox@Eng 2000-01-21

            gafter Neal Gafter (Inactive)
            wmaddoxsunw William Maddox (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: