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.
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.
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)