I forgot to mention--
There is "as implemented correctness", meaning today's JVMs and processors are highly "forgiving" of incorrect code, because implementing the guarantees otherwise would be too expensive without things like write-through caches. This is why there are huge amounts of thread-unsafe code that never fails--it's just getting lucky, and it's lucky 100% of the time on today's architectures.
Then there is "by the book correctness", strictly according to the minimal JVM requirements. This is how code should be written, and it is the only way to write code that will run correctly across various processor architectures, JVM implementations that might be coming.
Consider a processor that could tag every 32 bytes as independently flushable (but never write-through) from a per-core cache, with each core having its own 4MB cache in, say, an 8-core system. You can bet that GlassFish (and probably every other server out there) would crash instantly in such a scenario--the code is just getting lucky on today's systems.
[Message sent by forum member 'llc' (llc)]
http://forums.java.net/jive/thread.jspa?messageID=245862