Link Details

Comments on your blog are not working for me, so I'll comment it here.

You went bit too far with point 6. Mutex is NOT required there - making value volatile is enough for what you want. I suppose that you got confused by the idea that 'long' updates might be not atomic - but when you use generics, you are not using 'long', you are using java.lang.Long. This means that T value is of type reference, which is guaranteed to be atomic.

On top of that, you are asking for deadlock in equals method. If two threads are calling equals on two Mutables against each other, there is a chance they will deadlock after getting their own mutex and waiting for other mutex in 'another.get()'.

Thanks Abies - good catch. I have updated the code on my blog. I had put the mutex so that equals(), hashCode() and toString() methods could be atomic. Given that this may not be very useful besides the locking overhead on every operation, I have removed the mutex altogether.

I guess the "Mutable" wrapper is still useful in the sense consumer threads can lock on this object without having to worry about null values.

Sorry for nitpicking, but hashcode and toString would be also atomic - you will get either old or new reference to wrapper Long, but there would be no possibility of seeing half-update when calling hashcode/toString on that Long.

As far as equals is concerned, it is hard to speak about atomicity here. In any case, just copying the reference inside local variable and the using it further gives you as much guarantees as any kind of lock inside (sans deadlock).

That's right @equals(). In fact I was wondering about atomicity of methods in case of regular "nested" objects (that could have mutable state within) - so Long is just a special case that is immutable already. I would perhaps change the sample usage in #6 to reflect this.

1. The 'Shared mutable assignments' code is currently (as of posting this) totally broken. It cannot be fixed without locking down the whole object (which would be pointless).

2. Immutability (not only in Java) primarily refers to immutable VALUES (a.k.a. immutable value 'objects'). It makes no sense to make Beans or Business Objects immutable. See also:

http://wiki.java.net/bin/view/Javapedia/ImmutableObject
http://www.javapractices.com/topic/TopicAction.do?Id=29

Re 1: Yeah, I realized the same and I have updated the code on my blog. It fixes a race condition in equals() and potential NPE issues.

Re 2: I agree Beans cannot be immutable - there are frameworks that cannot work without a default constructor (e.g. JSP+Tomcat). However, I personally I don't prefer beans in general and try to avoid frameworks that insist on using beans.

In an update I have removed Mutable> abstraction entirely on the blog post.

Good idea.