java.io.File field "path" is not declared final

[David Holmes]

On 16/02/2012 11:55 AM, Weijun Wang wrote:
> It's almost final. That field is only changed in readObject(), which is
> effectively a constructor.

Yes but because it is not final, if a File instance is shared and 
unsafely published then a thread using the File may see a wrong value 
for the path. People may wrongly assume that because the class is 
immutable that instances can be safely shared without needing to use 
safe publication.

It's not clear to me that this is a class for which we need publication 
guarantees however. But clarifying that either way would be a good thing.

David

> Max
>
> On 02/16/2012 01:34 AM, Rémi Forax wrote:
>> Reported by a user on the concurrency-interest mailing list,
>> File field "path" is not declared final but should be.
>>
>> cheers,
>> Rémi
>>
>> -------- Original Message --------
>> Subject: [concurrency-interest] File object is not immutable?
>> Date: Wed, 15 Feb 2012 19:00:59 +0400
>> From: Ruslan Cheremin <cheremin at gmail.com>
>> To: concurrency-interest at cs.oswego.edu
>>
>>
>>
>> I was very surprised to see that field "path" in java.io.File is not
>> final. I was treating File object in concurrency area is something
>> like String -- fully immutable, and completely thread-safe, even
>> data-race safe.
>>
>> Am I right supposing that File object is _not_ thread safe by itself
>> (as String does), and it is programmer's responsibility to safe
>> publish it between threads? Or may be it is some kind of hidden magic,
>> which makes File safe, even without explicit final? I mean, there is
>> native calls to FileSystem in constructor and deserialization, which
>> can create membars implictly...
>>
>>
>> ----
>> Cheremin Ruslan
>>
>>
>> On 02/15/2012 06:15 PM, Alan Bateman wrote:
>>
>>> On 15/02/2012 17:14, Rémi Forax wrote:
>>>>
>>>> The javadoc says File is immutable so it's a bug :(
>>>> There is no guarantee that the fs object will do a memory barrier.
>>>>
>>>> I think path is not final because of the serialization code but
>>>> it should be final and the seralization code should use
>>>> reflection or sun.misc.Unsafe.
>>>>
>>>> I've put Alan Bateman in CC because I don't know if java.io.File is
>>>> managed by the core team or the nio one.
>>>>
>>> Definitely bring it up on core-libs-dev as we should change it to be
>>> final.
>>>
>>> -Alan
>>