[Layne]: If the compiler is smart, it won't create either variable at run time. I'm pretty sure the variable will be created as a static field of the class in question (allocated in memory), however most code that uses the value will be optimized so that it inlines the value at compile-time rather than accesses the value of the field. You can see that the field still exists as a field of the class using reflection:
[Joyce]: The question is, is this optimization a guarantee on every compiler? For fields, yes, it's guaranteed by
JLS3 13.4.9: "If a field is a constant variable (�4.12.4), 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 the usage of the field unless they are recompiled." Other classes have inlined the old value; they won't see the new value. As usual, reflection is sort of outside the JLS rules, as the passage quoted doesn't take reflection into account as a possible way to "see" the value of a field.
For a constant local variable, I don't know that there's any clear guarantee that all uses of the variable will be inlined with the value of the constant, as this doesn't really create a clear observable effect. (There's no way to recompile the variable without recompiling the method that uses it.) There are other effects that depend on whether the variable is constant or not, but I don't think they will tell us whether the value has necessarily been inlined. I suspect that yes it has been inlined, but I don't think there's a guarantee for a local variable. Not sure it really matters.
[Joyce]: If so, why declaring class-level constant is more readable than at method-level? I'm not convinced it is. If the constant is only used in one method, I'm inclined to define it where it's used, locally. One possible reason to put it at class level is because that's where come other people may expect to find it, and following expectations is usually a good thing in collaborative development. If indeed it's a reasonably well-established expectation, and I don't think this one is. Some people might expect it to be local, and others class level.
If the constant is defined within a method, then regardless of expectations, it's going to be pretty obvious where to find it, since the only time you care about it is when you're looking at that method, and it's defined right there. (This assumes you keep your methods short enough to easily see the whole thing onscreen at one time, a principle that I think is a lot more important than where you declare a constant which is only used in one method.) And when reading the method - if you don't notice the declaration, how would you know it's a constant anyway? (If only there were some standard, well-established way of indicating a constant simply by the variable name.)
Any given variable you may encounter may be local, or class/instance level. If you can't tell from the name which it is, then you may just have to check both places. Unless it's obvious because it's already right in front of your face, defined in the same context it's used.
Personally I don't think this matters much either way. Of course Marilyn may be able to give a better perspective on the reasoning here.