Miranda methods and Methods added by Code Generators

[maurizio cimadamore]

Hi,
the compiler internally uses the IPROXY flag to mark Miranda methods:

       146      /** Flag is set for compiler-generated abstract methods that implement

       147       *  an interface method (Miranda methods).

       148       */

       149      public static final int IPROXY           = 1<<21;


The code you are looking at discards SYNTHETIC methods because this 
method is meant to return an user-defined implementation of a given 
method symbol in a given class - and a SYNTEHTIC method is, by 
definition, not a user-defined method. This check turns out particularly 
useful when the class contains one or more bridge methods (the method 
that javac has to emit to preserve overriding in the face of type-erasure).

In other words, javac is not complaining because it thinks that 
getAdvisor() is a Miranda method - it just complains because it sees a 
class not overriding all methods from its superinterfaces.

Maurizio

On 06/08/2010 16:21, Andrew Dinn wrote:
> Dear Compiler Devs,
>
> The JBoss AOP team recently ran in to a problem when transforming an 
> abstract class offline (see https://jira.jboss.org/browse/JBAOP-731 
> for details). The AOP transform operation loads the bytecode for a 
> class, call it X, manipulates it to insert, inter alia, a getAdvisor() 
> method then rewrites the classfile. Method getAdvisor is SYNTHETIC and 
> has a Code attribute. It is _NOT_ ABSTRACT.
>
> When javac subsequently tries to compile the source for Y extends X it 
> complains that Y does not implement getAdvisor(). It turns out that 
> javac is assuming that the SYNTHETIC implementation found in the 
> transformed classfile for X is a Miranda method even though it is not 
> ABSTRACT. The relevant code is in method
>
> com.sun.tools.javac.code.Types.implementation(MethodSymbol ms, 
> TypeSymbol, Types, boolean)
>
> The offending code is
>
> 1967
> 1968    MethodSymbol impl = cache.get(origin);
> . . .   if (impl == null) {
>             for (Type t = origin.type; t.tag == CLASS || t.tag == 
> TYPEVAR; t = types.supertype(t)) {
>                 while (t.tag == TYPEVAR)
>                     t = t.getUpperBound();
>                 TypeSymbol c = t.tsym;
>                 for (Scope.Entry e = c.members().lookup(ms.name);
>                      e.scope != null;
>                      e = e.next()) {
>                     if (e.sym.kind == Kinds.MTH) {
>                         MethodSymbol m = (MethodSymbol) e.sym;
>                         if (m.overrides(ms, origin, types, 
> checkResult) &&
>                             (m.flags() & SYNTHETIC) == 0) {
>                             impl = m;
>                             cache.put(origin, m);
>                             return impl;
>                         }
>                     }
>                 }
>             }
>         }
>
>
> My contention is that this is a bug. javac should only regard ABSTRACT 
> SYNTHETIC methods as Miranda methods. After all, Miranda methods are 
> all abstract are they not?
>
> Is there some good reason why _ANY_ SYNTHETIC method has to be 
> rejected? If not then the recommended patch would be to change the 
> 'if' condition at line 1978/9 above to
>
>                         if (m.overrides(ms, origin, types, 
> checkResult) &&
>                             (m.flags() & (SYNTHETIC|ABSTRACT)) != 
> (SYNTHETIC|ABSTRACT) {
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Software Engineer, JBoss
> Red Hat UK Ltd
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
> Street, Windsor, Berkshire,
> SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA)  and Brendan Lane (Ireland)
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100807/774dd0eb/attachment.html