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.

One unstated assumption is that the keys and values in the map are individually thread-safe or effectively immutable.

I don’t buy Peter’s argument, though. While the elements of the map may eventually “become visible” without final, it may be seen to violate some obvious invariants in the absence of the final or other ordering guarantees. For example, you could iterate the keys of the LHM but have containsKey() return false for one of those keys. That would clearly be confusing.