Bug 50253

Summary: compiler enhanced errors: static fields hiding
Product: [Eclipse Project] JDT Reporter: quartz quartz <quartz12h>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: P3    
Version: 3.0   
Target Milestone: 3.0 M7   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description quartz quartz CLA 2004-01-19 19:46:30 EST 
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.
Comment 1 Philipe Mulet CLA 2004-01-20 03:50:09 EST 
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 ?
Comment 2 quartz quartz CLA 2004-01-20 08:52:27 EST 
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.
Comment 3 Philipe Mulet CLA 2004-01-20 09:25:47 EST 
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.
Comment 4 Philipe Mulet CLA 2004-02-13 07:45:59 EST 
dup
Comment 5 Philipe Mulet CLA 2004-02-13 07:47:17 EST 
see comment in bug 51075

*** This bug has been marked as a duplicate of 51075 ***