> 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.
Considering the contract is not enforced at runtime (in current
implementation), it's easy to violate it (especially with concurrent
accesses).
And, as practice shows, it's very hard to track down bugs causing change
in behavior between different execution modes (interpreter vs compiled
code vs recompiled code).
To sum it up, standardizing something which increases complexity of the
area which is already quite complicated (JMM) doesn't look like a wise
move in a long term.
Best regards,
Vladimir Ivanov