Community
Participate
Working Groups
I was surprised that the following would not compile: public class AOuter { protected abstract class AInner { protected abstract void action(); protected final double someFunction() { return someFunction("whatever"); } } public double someFunction(String name) { if ("half".equals(name)) return 0.5; return 0.0; } }
(I'm also surprised that bugzilla keeps cutting off my comments without notification. Now I have to reconstruct the rest of my previous message.) In essence, javac gives the same error. Both are in line with JLS, which says that a method of a given name "shadows" all methods of the same name in an enclosing class. (This is even though the methods in the enclosing class may have different signatures.) Since this was a surprise to me, I suspect that this aspect of shadowing is not well-understood, and that eclipse users would be well-served if the compiler message would use the term "shadow" so that users can understand what's going wrong by indexing JLS. For example: "Method someFunction(java.lang.String) in type compilerBugs.AOuter is shadowed and inaccessible via simple name within type compilerBugs.AOuter.AInner" Obviously, it would only be appropriate to use if a method of the correct signature existed, but was inaccessible due to shadowing.
The method lookup never reaches the outer type since it finds a selector match with 'someFunction'. We never find the outer implementation. Java has its roots in C++ which did function name overloading, not in Smalltalk which was a pure OO language and considered a method's signature to be more than its selector. I accept that some users may find this confusing depending on their background, but we need to keep our error messages in line with javac.
Indeed, the namelookup process cannot be used to achieve this, since it doesn't reach the outer method. However, maybe the method verification process could provide an optional hint about this (like we do when warning about overriding package default methods across packages). Time permitting for 2.1, but likely we will keep for later.
Phillipe: Do you want to tag all methods which 'shadow' an inherited method with an incompatible signature? Or just methods defined by nested types? In other words, should we detect & report a warning against foo(String): class A { void foo() {} } class B extends A { void foo(String s) {} }
I would only report in the nested scenario. This is likely a collision situation which would remain local to the same unit. I would actually not do it for 2.1, but keep it for 2.2 unless it is trivial (no new code to add)
Deferred
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
