From http://mail.openjdk.java.net/pipermail/compiler-dev/2007-June/000062.html

We have a problem.  Actually, we have two, one for RegularFileObject and 
one for ZipFileObject.

In JavacFileManager, RegularFileObject.equals does not object the 
general contract of equals. Here is the relevant code:

        @Override
        public boolean equals(Object other) {
            if (!(other instanceof RegularFileObject))
                return false;
            RegularFileObject o = (RegularFileObject) other;
            try {
                return f.equals(o.f)
                    || f.getCanonicalFile().equals(o.f.getCanonicalFile());
            } catch (IOException e) {
                return false;
            }
        }

        @Override
        public int hashCode() {
            return f.hashCode();
        }

The contract for Object.equals says that:
"Note that it is generally necessary to override the hashCode method 
whenever this method is overridden, so as to maintain the general 
contract for the hashCode method, which states that equal objects must 
have equal hash codes."

The problem is that getCanonicalFile will equate a relative file ("foo") 
with its absolute equivalent ("/home/jjg/foo"), even though they have 
different hashcodes.

There are two possible solutions. For maximum compatibility, hashCode() 
should use getCanonicalFile for the hashCode (and hope that you don't 
get an IOException.)
Arguably a better solution for both equals and hashCode would be to use 
getAbsoluteFile instead of getCanonical file, but that would potentially 
and subtly change the semantics so that symbolic links would not be 
considered equal.

 From a historical perspective, the getCanonicalFile code in 
RegularFileObject can be traced back to the need to do case-equivalent 
fillename matching on Windows. (See 1.5.0_10 ClassReader.java, line 1819 
and following.)  However, that code was already outdated, since 1.5.0_10 
Win32FileSystem.java shows that filename matching ignores case.



The other issue is with ZipFileObject, which is related but different.   
This has a novel and probably incorrect definition of equality, which 
also violates the general contract of equals. Here's the code from 
ZipFileObject.

        @Override
        public boolean equals(Object other) {
            if (!(other instanceof ZipFileObject))
                return false;
            ZipFileObject o = (ZipFileObject) other;
            return zdir.equals(o.zdir) || name.equals(o.name);
        }

        @Override
        public int hashCode() {
            return zdir.hashCode() + name.hashCode();
        }

The novelty is the '||', which means that two ZipFileObjects are the 
same if they share the identical same zip file container, or (yes, or) 
they have the same path within a zip file.   Even if you change the || 
to &&, we still have an additional but relatively minor issue -- that 
the condition for equality of zipfiles is inconsistent with the 
condition for equality of regular files. (ie. zip file equality doesn't 
compare paths and they don't get the same canonical treatment.)


So the proposal is the following
- fix ZipFileObject equality to use && not ||
- fix ZipFileObject to compare zip files the same way we compare regular 
files (whatever we decide that should be)
- consider using absolute paths, and not canonical paths for 
FileObject.equals, at a risk of a minor behavioral change
- there is already a method StandardFileManager.IsSameFile; this should 
use canonical paths to determine same-ness


-- Jon