JSR199 FileObjects don't obey general contract of equals.

[Jonathan Gibbons]

Yes, the proposal is to move towards using getAbsoluteFile for equals()
and getCanonicalFile/getAbsoluteFile is isSameFile().

This would be a behavioral change for equals() and will need to be
processed appro-ccc-priately.

-- Jon

On Jun 21, 2007, at 11:22 AM, Peter Ahé wrote:

> You're right about that.  I guess it would be better to use
> getAbsoluteFile only, which was always the intent.
>
> Cheers,
> Peter
>
> On 6/21/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> Really?
>>
>> Compiler gets the canonical path of one file successfully.
>>
>> Network goes down (It has been known to happen, even at Sun.)
>>
>> Compiler tries to get the canonical path of a similar file, using an
>> NFS path like /net/machine.domain/file, which fails because
>> machine.domain is inaccessible. java.io.File throws an IOException
>> because it cannot determine the canonical file.
>>
>> The compiler falls back to using getAbsoluteFile, and incorrectly
>> determines these files are different, even though they might have
>> been symlink equivalent had the network been working.
>>
>> That's not a bug in java.io.File.  It is arguably a bug in the
>> compiler for using File.getCanonicalFile in JavaFileObject.equals.
>>
>> -- Jon
>>
>>
>> On Jun 21, 2007, at 10:39 AM, Peter Ahé wrote:
>>
>> > On 6/21/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> >> My concern would be the unspecified nature of IOExceptions, and
>> >> whether network failure outside the virtual machine could lead the
>> >> code to incorrectly determine that two files were different,  
>> when in
>> >> fact they were "symlink-equal" in a part of the path that is no
>> >> longer accessible by virtue of the network failure.
>> >
>> > Unless somebody is deliberately trying to foil the compiler, that
>> > situation must be characterized as a bug in java.io.File, not the
>> > compiler.
>> >
>> > Cheers,
>> > Peter
>>
>>