This is exactly addressed by the JLS in 15.12.3. “Compile-Time Step 3: Is the Chosen Method Appropriate?”.
If the form is TypeName . super . [TypeArguments] Identifier, then:
- […]
- If TypeName denotes an interface, let
T
be the type declaration immediately enclosing the method invocation. A compile-time error occurs if there exists a method, distinct from the compile-time declaration, that overrides (§9.4.1) the compile-time declaration from a direct superclass or direct superinterface ofT
.
The JLS goes on to explain why the rule is in place:
In the case that a superinterface overrides a method declared in a grandparent interface, this rule prevents the child interface from “skipping” the override by simply adding the grandparent to its list of direct superinterfaces. The appropriate way to access functionality of a grandparent is through the direct superinterface, and only if that interface chooses to expose the desired behavior.
So it more or less exists specifically to stop you from doing what you’re trying to do.
But the JLS also seems to acknowledge your workaround:
(Alternately, the developer is free to define his own additional superinterface that exposes the desired behavior with a super method invocation.)