Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Immutable Object vs. Unsynchronized State

Immutable Object vs. Unsynchronized State



Joshua Bennett discusses immutable objects, what they are good for, when they are recommended to be used and when are to be avoided.


Joshua Bennett is a technical architect for CME Group. His days are spent designing and developing highly scalable and concurrent systems which need to handle the rigors of the high throughput low latency world of the futures and options trading industry. When he isn't working, he spends his time preparing for the inevitable zombie apocalypse by learning to operate various motorized vehicles.

About the conference

Strange Loop is a developer-run software conference. Innovation, creativity, and the future happen in the magical nexus "between" established areas. Strange Loop eagerly promotes a mix of languages and technologies in this nexus, bringing together the worlds of bleeding edge technology, enterprise systems, and academic research. Of particular interest are new directions in data storage, alternative languages, concurrent and distributed systems, front-end web, semantic web, and mobile apps.

Recorded at:

Feb 22, 2011

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • CopyOnWrite*

    by István Kovács,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A minor correction @12:00:
    CopyOnWrite* are not methods but classes. They do not return a new data structure when you modify them (that would mean CopyOnWriteArrayList breaks the contract of List, where add() is defined to return a boolean success indicator, not a List reference). They do, in fact, create a new data structure for internal storage; existing iterators will use the original data structure, and won't see any modifications, such as new elements added to the list; they will never fail with ConcurrentModificationException. The new data structure (array) is never exposed, and no new CopyOnWrite* object is returned.

    (ps. not all fields of String are final, yet it is effectively immutable; check its source if you're interested)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p