Community
Participate
Working Groups
BETA_JAVA8 Compiler needs to be enhanced to support the new InterfaceName.super.method() construct. The following program which should compile alright fails to compile as of now: // ------- interface I { void foo() default {} } class X implements I { public void foo() { I.super.foo(); } } We issue a message: "No enclosing instance of the type I is accessible in scope"
We need to ensure the additional constraints that (from tentative amends to JLS) "The named interface must be a direct superinterface of the type declaration, T, immediately enclosing the expression. In addition, it is a compile-time error if there exists a method, distinct from the named method, that overrides the named method from a direct superinterface of T."
(In reply to comment #1) > We need to ensure the additional constraints that > (from tentative amends to JLS) > > "The named interface must be a direct superinterface of the type > declaration, T, immediately enclosing the expression. In addition, it is a > compile-time error if there exists a method, distinct from the named method, > that overrides the named method from a direct superinterface of T." This part needs to go into MessageSend as well as ReferenceExpression. Please see last bullet in 15.28.1 - TIA.
Released for BETA_JAVA8 via commit a1d61f4860d08002c8a193d70dccc7a85c870208 based on this rule in 9.4.1 (spec version 0.6.1): "An overridden default method can be accessed by using a method invocation expression (15.12) that contains the keyword super qualified by a superinterface name." Before closing this issue I will check whether we are too permissive now, viz, whether we allow calling super methods that are not "an overridden default method". I have found no mentioning of default methods in 15.28.1, so I'm not sure what should be done in this regard. Maybe something got removed from the spec? My fix mainly happened directly in QualifiedSuperReference.
(In reply to comment #3) > I have found no mentioning of default methods in 15.28.1, so I'm not sure > what should be done in this regard. Maybe something got removed from the > spec? The same restriction in comment#1 applies to materialization of method references of the form I.super::foo See the reference to this bug in ReferenceExpression.resolveType > My fix mainly happened directly in QualifiedSuperReference. May be things will already work, I'll add a test and see.
(In reply to comment #4) > The same restriction in comment#1 applies to materialization of method > references of the form I.super::foo Looking at the part on default methods, I never found that rule in the spec, but now I find this: 15.28.1: "It is a compile-time error if the method reference is of the form TypeName . super :: NonWildTypeArgumentsopt Identifier, and either of the following are true: ... The TypeName denotes an interface and, where T is the type declaration immediately enclosing the method reference, there exists a method, distinct from the compile-time declaration, that overrides (9.4.1) the compile-time declaration from a direct superinterface of T." It's strange to see two different versions of this constraint, as 9.4.1 only has: "An overridden default method can be accessed by using a method invocation expression (15.12) that contains the keyword super qualified by a superinterface name." Are both constraints just different ways of saying, TypeName.super.m cannot reach up more than one level in the chain of overrides? As for the second version, to me this sounds like bending the interpretation of "an overridden default method". Should we request clarification?
(In reply to comment #5) > (In reply to comment #4) > > The same restriction in comment#1 applies to materialization of method > > references of the form I.super::foo > > Looking at the part on default methods, I never found that rule in the spec Never mind that part, I finally found it in 15.12.3, slightly rephrased as: "Otherwise, if the 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 of T." Sorry, I just had now idea where I should be looking and there was no direct search match. With this find, consistency with 15.28.1 is established.
Note that I've implemented the constraint from 15.12.3 in MessageSend via commit 7915a529d4dab8b70a0cdb9189fc342b9112ed8e (on behalf of bug 404649). Now the same just has to be transfered to ReferenceExpression to implement the corresponding constraint from 15.28.1. We may also want to check if the type level constraint from 15.28 (in part B) is correctly handled via QualifiedSuperReference (see commit 86ee968d8acf90a0a75c72085f72a3416b02186d).
(In reply to comment #7) > Now the same just has to be transfered to ReferenceExpression to implement the > corresponding constraint from 15.28.1. > We may also want to check if the type level constraint from 15.28 (in part B) is > correctly handled via QualifiedSuperReference (see commit > 86ee968d8acf90a0a75c72085f72a3416b02186d). I guess bug 404649 is actually the better home for the additional checks regarding ReferenceExpression, will re-open that one and close this bug.
