java.io.File field "path" is not declared final
weijun.wang at oracle.com
Thu Feb 16 01:55:11 UTC 2012
It's almost final. That field is only changed in readObject(), which is
effectively a constructor.
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.
> -------- 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
More information about the core-libs-dev