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
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
- duplicates
-
JDK-4019348 javac does not diagnose bad classpath
-
- Closed
-
-
JDK-4109418 Compiler can give spurious errors when using -depend flag.
-
- Closed
-
-
JDK-4032273 Spurious/misleading errors when package declaration and sourcefile path disagree
-
- Closed
-
-
JDK-4227952 Javac does not report errors in CLASSPATH
-
- Closed
-
-
JDK-4257856 Warning for java files misplaced from their package dir
-
- Closed
-