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

[Weijun Wang]

It's almost final. That field is only changed in readObject(), which is 
effectively a constructor.

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
>