javac can't find classes if it is invoked on a file
which is specified by a path using forward slashes.

This makes it more painful than necessary to write makefiles
that work on NT and Solaris.

e.g.:

> javac -g -deprecation PackageName/ClassName.java
PackageName/ClassName.java:38: Public class PackageName.ClassName must be 
defined in a file called "ClassName.java".
public abstract class ClassName extends Thread  {
                      ^
1 error
>

But, this works:

>javac -g -deprecation PackageName\ClassName.java
>

======================================================================

Use backslashes on Windows machines!
======================================================================

Verified behavior with 1.1.3fcs on NT.
He's right; according to mr, this should work, with the file name
getting automagically translated by some native io method somewhere.

  xxxxx@xxxxx   1997-07-11

There check was being performed by comparing the command line string
to what the compiler thought it should be using .equals().  The fix
was to instead check canonified names.

  xxxxx@xxxxx   1998-05-05

My "fix" above was incorrect, and is being backed out.  The real problem
is that java.io.File.getName() represents paths as strings rather than with
a real data structure.  Mark assures me that problem will get fixed very
soon, which will cause the javac problem to go away.

I'm moving this back from integrated to committed until I can confirm
that the java.io fix fixes this problem as well.

  xxxxx@xxxxx   1998-05-07

Confirmed fixed with putback for 4102262.

  xxxxx@xxxxx   1998-05-13