JSR199 FileObjects don't obey general contract of equals.

[Jonathan Gibbons]

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