There are several longstanding ease of use issues associated with the
behavior of the compiler as a tool (command syntax and semantics), including
several that promote common errors in usage.

1. If the -d directive is not specified, classes are just dumped in the
current working directory, where they will not be found if they were in
fact declared to belong to a package (4239214).

2. If the -d directive is specified, classes will be placed within the
specified directory according to their package declarations. The target
directory will not be searched, however, unless it is explicitly added to
the classpath. It should be added by default, to avoid the confusing
diagnostics that appear when the target directory and the classpath are not
in sync.

3. The compiler currently requires that the '.java' extension be specified
explicitly for source files. Some users would prefer that '.java' be supplied
by default (4231433). Alternately, it might be convenient if the name of a
class could be specified (as in the VM), and the source file determined by
searching the sourcepath.

4. The compiler's treatment of dependencies and automatic recompilation is
inadequate. Without the -Xdepend switch, the JDK 1.2 compiler does not
guarantee that transitive dependencies are taken into account. That is, if
source file being compiled depends directly on a class file that is up-to-date
with respect to its source, the dependent class will not be recompiled even if
it in turn depends on a class file that is out-of-date. The new JDK 1.3
compiler doesn't even implement the -Xdepend switch, which was implemented
hightly inefficiently. An efficient implementation requires that a compact persistent "dependency model" be maintained for an entire collection of related
source files -- otherwise, it is necessary to open and parse all of the
transitively referenced class files in order to extract the dependency data.
In the current method of invoking the compiler, however, there is no notion
of a "project", or some other collection of related files that is to be kept
up to date. One option is to identify the set of classes contained in a
JAR file (or a "JAR file image" directory) with such a project, and provide a
means to compile directly into a JAR file. This has been proposed for other
reasons, namely host filesystem independence, in 4030394. Another approach
would be to permit compilation of an entire package at once (4014784). The
approach described there does not, however, provide for a persistent dependency
model, thus it is no surprise that the submitter reports little increase in
incremental compilation performance.

5. Currently, all source files listed on the command line are recompiled
without question. It would be useful if we could recompile only those
source files that are out of date. This is a reasonable fallback position
with respect to item 4 above. RFE 4229449 proposes that this behavior be
controlled by a switch.

6. The compiler could be multithreaded for better performance on multiprocessor
systems, once a reliable dependency-tracking mechanism has been incorporated.
See 4229449.

7. Provide varying levels of verbosity for the -verbose option.
Currently, the output is best suited to diagnosing compiler problems
rather than simply seeing which files were re-compiled. (4035341)

8. Provide -deprecation:all to force deprecation warnings even when
the deprecated methods are compiled in the same compilation. Also,
-deprecation:none to suppress deprecation warnings entirely.
(4233889)

An internal proposal for a new command-line syntax and semantics was
floated midway during the JDK 1.2 development cycle, but was too late
for inclusion, and took a back seat in JDK 1.3 to the move to the new
compiler codebase. This issue should be revived at this time.

william.maddox@Eng 2000-01-11