JSR199 FileObjects don't obey general contract of equals.

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Thu Jun 21 06:41:08 PDT 2007

You're correct that using getAbsoluteFile is a better backup for when  
getCanonicalFile fails.

However, technically, we still are at risk for failing the general  
contract of equals. I'm
reminded of the Java Puzzler at JavaOne this year. It involved URLs  
and equallity,
and the the fact that URLs could sometimes be equal depending on  
whether a
host's DNS service was available. (I hope I got that right).

I'd hate for JavacFileManager to show up in a puzzler because it  
depends on whether
NFS was running correctly or nor :-)

That all being said, I agree this is arguably the least perturbation  
of semantics that will
work most of the time.

-- Jon 

On Jun 20, 2007, at 11:20 PM, Peter Ahé wrote:

> On 6/20/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> On Jun 20, 2007, at 10:49 PM, Peter Ahé wrote:
>> > On 6/20/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> >> So the proposal is the following
>> >> - fix ZipFileObject equality to use && not ||
>> >
>> > That may fix the hashCode issue, but are you sure "foo" and its
>> > absolute equivalent will remain equal?
>> >
>> That's why I added the 2 bullet in the list -- these were a set to be
>> taken together,
>> not alternatives; sorry if that was not clear.
> Oh, I mistook it for RegularFileObject.  I guess I skimmed the second
> part.  ZipFileObject.equals is clearly broken.  Ignoring that issue,
> and focusing on only one thing at a time: I think you need to use
> getCanonicalFile in RegularFileObject.  However, you may want to
> consider wrapping it in:
> File safeGetCanonicalFile(File f) {
>           try {
>               return f.getCanonicalFile();
>           } catch (IOException e) {
>               return f.getAbsoluteFile();
>           }
> }
> And you may want to ensure this is only calculated once per file
> object.  However, you must keep the user specified file name around.
> Otherwise, diagnostics gets messed up.
> Cheers,
> Peter

More information about the compiler-dev mailing list