> On Jan 15, 2018, at 6:00 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> > wrote: > > >> This isn’t much different from the already allowed fine tuning of memory >> model effects (e.g., observing stale values from a plain write). In those >> scenarios, as is the case with @Stable, developers have to be aware of and >> honor the respective contract. It could be argued that bugs arising from >> contract violations of @Stable are easier to catch, due to their persistent >> nature. > > The crucial difference is that @Stable doesn’t obey JMM while others do > (though you can break that as well using Unsafe or Reflection API), so all > the tricks programmers rely on (locks, finals, volatiles, fences) don't work.
Right and also VarHandle and AtomicReferenceFieldUpdater, which let you weaken the effect of a write, such that stale reads on the reading side may occur. -Jason
