If we assume that keys and values in map are individually effectively immutable/immutable we can surely say that SomeClass is immutable. With regard to your answer to Peter Veentjer comment how come that immutable object is not published safely ? What i do understand from your book is that immutable objects are always safely published…

If an object is immutable that it can be safely published through any mechanism (according to your book). By any mechanism i understand any approach to make an instance of SomeClass visible to other thread, e.g storing an instance of SomeClass in some public field of other class instance.

I think you have overlooked a part of my argument or I didn’t express myself clearly, because a safe publication need some kind of synchronization action like a volatile or a lock for example.

If an object has publication problems (all fields are normal and not volatile/final/used in a synchronized context) the object can be safely used in a multithreaded environment if:
-in some point in time this object is published correctly by using volatile/final/synchronized context and not before
- the object is not changed after this publication

The ordering gurantees for the volatile write/synchronized unlock are so strong that instruction before them can’t jump over them, so constructor code for example is not allowed to be executed after this publication, The same goes for the ordering gurantees of the volatile read/synchroned lock: the ordering guarantees are so strong that instructions that come after them can’t jump in front of them.

In your book have written a small chapter about it: piggybacking on synchronization. And I think it is one of the most powerfull features of the new JMM (since objects with publication problems can be used safely, for example by using a blockingqueue or concurrentmap).

Occording to the JMM in the case of the SomeClass (without final map):
1) there is a happens before relation between the creation of the someclass and the publication (using a volatile variable for example) : program order rule
2) there is a happens before relation between the write and read of a volatile variable (volatile variable rule)
3) there is a happens before relation between the read of the volatile variable, and the usage of the internals

And since the happens before rules are transitive, there is a happens before relation between action1 and action3.
So the SomeClass can safely be used in a multithreaded environment if it is published safely (and not changed after construction).

If I got this wrong, it would mean that there is a serious holes in my understanding of the JMM and I would like to understand what I’m missing.