The excemptions outlined in the JEP still allow people to do pretty much whatever they want as granular as they want. They can even wholesale revert to the old

The excemptions outlined in the JEP still allow people to do pretty much whatever they want as granular as they want. They can even wholesale revert to the old behavior. I really don't see the issue. > And, likewise, if the JVM never sees a write instruction to a certain field, except once in the constructor, it should be able to treat it as if the field were final, and avoid reloading it after method calls. If it loads a class with an instruction that writes that field, it has to recompile all those methods. Right now, many opportunities for this optimization cannot be used because `final` for non-static fields cannot be relied upon. If such a field modification happens, then it's far more difficult to locate all the code that is the result of constant propagation from that field's original value. The impact of changes in the other scenarios is quite limited in comparison. > None of this should be news to the JVM engineers. I know how JIT compilers work, and the OpenJDK team knows as well of course. Which is exactly why they pursue this change. Deoptimizing and recompiling simply sucks for performance because this is time the application could spend on far better things.