Community
Participate
Working Groups
Example. Class B extends A. A defines a public static field "version". B defines also a field "version" (static or not, B.version gives the problem) Compiler reports that B.version is hiding A.version, which of course if false, since they are in separate domains (the classes) and A.version is not inherited by B.
Java doesn't prevent from hiding variables, though from a code readability angle, it is probably a bad idea. This is why this optional diagnosis got added. It is off by default, and doesn't distinguish static vs. non static variables. Are you suggesting a better problem message ?
No, I'm suggesting there should be a distinction of static fields. I know there are many best-practice based problems and it should flag potential bugs, but it should not create problems that cannot exist, like static field hiding. I raise that problem to the error level, just to be sure our code is clean. But I keep finding errors in almost ALL opensource projects, even generated code from some toolkits. I was expecting at least a sub-checkbox like for argument hiding filend, in constructor/setters. Thanks.
We have to keep the controls reasonable so as not to have a combinatory explosion of our preferences number. I am not saying this one is not a bad idea, but I could imagine many more levels of discrimination along the same path. Will keep for later if this becomes a popular request.
dup
see comment in bug 51075 *** This bug has been marked as a duplicate of 51075 ***
