JDK-6588234 : ambiguities between up-level and inherited names are not diagnosed
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2007-08-02
  • Updated: 2013-03-20
  • Resolved: 2013-03-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Relates :  
Description
The following code should fail to compile, but it compiles silently:
	//JCK test innr005, bug #
	class InheritHideBug {
	    static class S {
		void m() { }
	    }

	    void m() { }

	    class C extends S {
		{
		    m();		// BAD
		}
	    }
	}

The compiler in 1.1, 1.2, and 1.3 (as documented in the pre-generics whitepaper specification) featured the "Mother May I" rule, which requires the programmer to specify an explicit qualifier when an unqualified method name matches both an inherited and an outer method definition.  This was dropped in 1.4 with the switch to a new javac code base.  It is a recurrence of 4030368, and additionally the language specification also failed to include this rule (by design; see blogs.sun.com/jrose).

The ambiguity has been observed as a "Java puzzler" by Neal Gafter and Gilad Bracha.  There is no need to keep this puzzler in the language.  At least issue an obnoxious warning.

Comments
JLS8 will call out the "Mother May I" rule more clearly in overload resolution, but the language is what it is.
20-03-2013

EVALUATION Puzzlers are bad, and comb semantics [1] have fallen out of favor. But it is hard to imagine sneaking the Mother May I rule into the language now. An obnoxious warning doesn't need to be mentioned in the JLS, but I recognize there isn't likely to be such a warning in javac without a note in the spec. [1] http://blogs.sun.com/jrose/entry/scope_ambiguities_between_outer_and
30-01-2008