Sometimes I want a express that a static field is unlikely to change, so the VM should consider it has a constant,   but it may changed.   And because we all live in a threaded world, if the static field is changed   I want that all threads that want to read the field value to notice that the value has changed like   a volatile field. Take by example the default Locale that you can obtain using Locale.getDefault(),   it's unlikely that this value will change, but it may change, there is a Locale.setDefault().

The idea is that default Locale is mostly a constant, so  when a code that call getDefault is JITed, the VM should consider it as a constant i.e. the JIT should replace the call to getDefault() by a direct reference to default Locale object.  And if a code calls setDefault(), the VM should drop the JITed code and re-optimize it later.

Suppose that you have a magic class named   AlmostFinalValue,   a value wrapped in this class acts as a constant for the VM, so a code that call   getDefault will be replaced by a constant by the VM.   And if setValue() is called, the VM will deoptimize the code that use  getDefault if   the code was JITed and change the value of the default locale.   If the code still use getDefault, it will be re-optimized by with the new constant. 
Note that this deopt/reopt takes time so it's not a good idea to use an AlmostFinalValue   for storing a value which changes frequently.

public class Locale {
  private static final AlmostFinalValue<Locale> DEFAULT_LOCALE =
      new AlmostFinalValue<Locale>() {
        protected Locale initialValue() {
          return new Locale("default");
  private static final MethodHandle DEFAULT_LOCALE_GETTER =
  public static Locale getDefault() {
    try {
      return (Locale)(Object)DEFAULT_LOCALE_GETTER.invokeExact();
    } catch (Throwable e) {
      throw new AssertionError(e.getMessage(), e);
  public static void setDefault(Locale locale) {


How AlmostFinalValue works ?

All modern VMs, V8-cranksaft (Javascript/Google), IonMonkey (Javascript/Mozilla), Hostspot (Java/Oracle), J9 (Java/IBM)   are able to de-optimize a JITed code if an optimistic assumption doesn't hold anymore. 
In Java, we go a little bit further, JSR 292, foolishly you may say,   gives access to VM optimization/deoptimization to the mass* by providing a silver bullet named the   SwitchPoint.

A SwitchPoint can be seen as a volatile boolean which is true by default and that can be switched off once.   On a SwitchPoint, you can create a guard, an 'if' statement seen as a method handle** that takes two method handles as parameter   and execute the former if the boolean is true or the later otherwise. The JIT optimizes a SwitchPoint by considering that the boolean value is unlinkely to change so it will   remove the guard to always call the first method handle and if the SwitchPoint   is switch off, the VM will deoptimize the JITed code. In fact, in Hotspot, this is done lazily the code is just marked   as must be dropped when it will be called. So later, when code will be called again,   the VM will call the second method handle. The second method is the slow path, the path which is infrequenly called when there is an update,   it get the new value, see it as a constant method handle and protect it with a new SwitchPoint.   Then this new method handle is installed as the new target of a mutable method handle (a MutableCallSite + a dynamic invoker in fact).   So the new constant is installed and will be called when the DEFAULT_LOCAL_GETTER will be called. The method hande DEFAULT_LOCAL_GETTER is called using invokeExact which calls the method handle with no runtime conversion. As a game, I will offer a free beer at FOSDEM or Devoxx France to the first that will explain why you need the two casts in front of invokeExact ***.

The full code is here, and works well with latest jdk8 and jdk7u2.   With jdk7, the SwitchPoint was not fully optimized so the VM will fail to transform the default local value to a constant.

* In fact, JSR 292 was intended to be used by developers of dynamic language runtime (Jython, JRuby, Groovy, etc)   but when you provide a golden hammer, everybody will want to use it. 
** A MethodHandle is runtime typed function pointers.
*** People that have written the JSR 292 spec can't participate, sorry John, Dan and Fredrik :)