Community
Participate
Working Groups
I20080902-0800. I was renaming a method and refactoring correctly warned me about a shading conflict. I then continued anyway and was surprised that we don't have a JDT Core warning for that. Here's a test case: public class Test { class Inner { void m() { m(); } } public static void main(String[] args) { new Test().doit(); } private void doit() { new Inner().m(); } void m() { System.out.println("I think this is called"); //$NON-NLS-1$ } } Running that code results in a stack overflow which could have been detected if a warning would be reported on inner call to m();
Indeed. Would you expect strict matches to be reported or compatible matches ? e.g. class X { void foo(long l) { } class M { void foo(int i) { } void bar() { foo(0); } } }
I'm mainly interested in strict. Compatible could be nice too but I guess we would get some false positives here.
I would expect a problem whenever removing the method declaration in the nested class (or one of its supertypes) could make a reference point to another method (I guess that means 'compatible'). > if a warning would be reported on inner call to m(); For fields and local variables, we already have a warning on the *declaration* if it hides another field or variable. Should we also have a warning on the declaration of a shadowing method? Unfortunately, we can also have shadowing situations where there's no method declaration to blame, e.g. public class Y { public static void main(String[] args) { new Y().new Inner().bar(); } void run() { System.out.println("Y"); } void run(int i) { System.out.println("Y" + i); } class Inner extends Sup { void bar() { run(); // Sup#run() shadows Y.this.run(); } } } class Sup implements Runnable { public void run() { System.out.println("Sup"); } }
This feels like the refactoring prechecking about semantical shift... this would be slow to implement on normal compiler duty, I believe. Flagging the shadowing declaration like we do for fields/types etc... is simpler and likely produces expected results.
