It took us a while to unravel this one, but I think we did.
The JMM says that loads and stores of references, and of 32-bit-and-smaller primitive values, are atomic with respect to other loads and stores of the same variable. This means that you'll see a valid value, though it could be a stale one. For 64 bit primitives, it is treated as 2 32 bit loads, which are individually atomic.
The initialization safety guarantees -- that you see correct values of final fields even when loading a reference with a race -- rests on the atomicity properties above.
What this says is that tearing/non-tearing is a property of reference-vs-primitive-ness; accessing a (fat) value through a reference gives you *more guarantees* than accessing it directly. (Correspondingly, this has more costs.)
All of this is to say, as I think you are saying: primitives of a certain size were always tearable, and they still are; references never were, and they are still not.
As for tearability: from /this/ perspective 64-bit values are already technically tearable, so nothing new here. It's from a different perspective, that of writing a class, where expectations have to be weakened.
