A DESCRIPTION OF THE PROBLEM :
JLS § 13.4.9 "final Fields and static Constant Variables" says:

>If a field is a constant variable (§4.12.4), and moreover is static, then deleting the keyword final or changing its value will not break compatibility with pre-existing binaries by causing them not to run, but they will not see any new value for a usage of the field unless they are recompiled. This result is a side-effect of the decision to support conditional compilation (§14.22). (One might suppose that the new value is not seen if the usage occurs in a constant expression (§15.29) but is seen otherwise. This is not so; pre-existing binaries do not see the new value at all.)

>The best way to avoid problems with "inconstant constants" in widely-distributed code is to use static constant variables only for values which truly are unlikely ever to change. Other than for true mathematical constants, we recommend that source code make very sparing use of static constant variables.

The JLS is claiming that static fields are different to instance fields in this regard.

They are not.

Example:

    class A { final int foo = 123; }
    class B { int bar = new A().foo; }

When B is compiled, the value 123 is directly baked into the B.class file, as can be easily seen with javap. No reference whatsoever to the existence of a field named "foo" is present in B.class, even though the field is not static.