[concurrency-interest] Joda-Time immutability

David M. Lloyd david.lloyd at redhat.com
Mon Jun 20 13:45:45 EDT 2011


On 06/20/2011 12:32 PM, Stephen Colebourne wrote:
> On 20 June 2011 17:52, Attila Szegedi<szegedia at gmail.com>  wrote:
>> Well, to me it looks like it's implemented:
>> import java.lang.reflect.Field;
>> public class TestFinalField {
>>    public final int x = 1;
>>    public static void main(String[] args) throws Exception {
>>      TestFinalField tff = new TestFinalField();
>>      Field f = tff.getClass().getField("x");
>>      f.setAccessible(true);
>>      f.set(tff, 2);
>>      System.out.println(tff.x);
>>    }
>> }
>> This prints "1", and not "2". So, setting of a final field is actually
>> silently ignored with setAccessible(true), for better or worse. Without
>> setAccessible(), it will actually throw an exception. With the "final"
>> qualifier removed from the field, it prints "2", as expected. I tested it
>> with both latest Java 6 and on the b145 build of OpenJDK 7, and both behaves
>> as described.
>
> Well thats weird, because my change works and passes the tests in Joda-Time.
> https://github.com/JodaOrg/joda-time/commit/067983f2684fa9e9ca4af4ef73b09e2be2f70001#diff-8
>
> Anyone know what is going on? Can this be sufficiently relied on? I
> haven't really got a workable alternative.

AFAIK the only time you can count on this working is if you've 
constructed an object instance without calling its constructor (a la 
serialization).  In other words the JVM is allowed to assume that the 
final field won't change and optimize accordingly.

I wouldn't rely on this trick for updating a field outside of a 
readObject() method.

-- 
- DML


More information about the Concurrency-interest mailing list