Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ajdt-dev] Signature-matching bug in inter-method declarations?

Thanks Wes, Adrian,

I wish I had seen that bug report before I posted! I do agree that, at least, there should be a compiler warning/error. It would be a nice feature though. Is it a _deep_ challenge?

On a related note, I also wonder about protected inter-method declarations (https://bugs.eclipse.org/bugs/long_list.cgi?buglist=39457). Again, I wonder if is _this_ a deep implementation challenge or just low on the priority list?

The reason I ask is partly academic (I am curious about implementation) but largely pragmatic. I'm in the process of a decent-sized refactoring to AspectJ and have seen both of these missing features as practical limitations. (If you're curious about the details, I'll be happy to share them.)

(Oh, and if this is the wrong list for this, sorry! and feel free to reply on aspectj-dev.)

Thanks a lot for your help!


-phil


Wes Isberg wrote:

Hi Phil, all -

Good find - see also bug 50195:

   "overriding introduced methods with default access fails"
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=50195

where Jim said

This is a known limitation [...] Only publically introduced members can be overriden by standard Java code. A corollary of this is that only publically introduced members are generated with non-mangled names and are effectively visible to pure Java compilers.

In a future release we could relax this restriction for the case where the target class and the aspect are both in the same package and the target is not an interface. Personally I prefer the simpler rule that clearly separates public introductions from all others.

which suggests a compiler error is warranted, as is a warning
in programming guide's implementation.xml:

When declaring methods on target types, only methods declared public are recognizable in the bytecode, so methods must be declared public to be overridden in any subtype or to be called from code in a later compile using the target type as a library.

To find known limitations that might not have been documented,
search AspectJ compiler bugs for the keyword "info".

Wes


------------Original Message------------
From: Adrian Colyer <adrian_colyer@xxxxxxxxxx>
To: ajdt-dev@xxxxxxxxxxx
Date: Fri, Aug-27-2004 1:34 PM
Subject: Re: [ajdt-dev] Signature-matching bug in inter-method declarations?

On a quick look, I think I understand why this program might be breaking. It's a bug though - you should either get an error message at compilation time or a program that runs, but not a program that fails at runtime. In this case the program should run. Please submit a bug report against AspectJ and the compiler component. Thanks.

(FWIW, some implementation detail: when a non-public ITD is made on a target type, the method name in the target type is 'obfuscated' so that only the designated set of callers can effectively call it (this is also backed up with type checking). For a public ITD this is not necessary. I suspect the bug is to do with having one 'obfuscated' name and one plain name, *both* introduced by ITDs, and not realising before it is too late that a virtual dispatch to one should call the other - ie. that they have the same signature).
-- Adrian
Adrian_Colyer@xxxxxxxxxx



Philip Quitslund <philipq@xxxxxxxxxxx> Sent by: ajdt-dev-admin@xxxxxxxxxxx
27/08/2004 18:50
Please respond to
ajdt-dev@xxxxxxxxxxx


To
ajdt-dev@xxxxxxxxxxx
cc

Subject
[ajdt-dev] Signature-matching bug in inter-method declarations?






Hey All!

Running the test program below, I get the following error:

java.lang.AbstractMethodError: trouble.Trouble$A.ajc$interMethodDispatch2$trouble$getName()Ljava/lang/String; at trouble.Trouble$Bang.ajc$interMethodDispatch1$trouble_Trouble$Bang$trouble_Trouble$A$getName(Trouble.java) at trouble.Trouble$Bang.ajc$interMethod$trouble_Trouble$Bang$trouble_Trouble$A$toString(Trouble.java:40)
                at trouble.Trouble$A.toString(Trouble.java)
                at java.lang.String.valueOf(String.java:2131)
                at java.io.PrintStream.print(PrintStream.java:462)
                at java.io.PrintStream.println(PrintStream.java:599)
                at trouble.Trouble.main(Trouble.java:34)
Exception in thread "main"


public class Trouble {

    static abstract class A {}
    static class B extends A {}

    public static void main(String[] args) {
        System.out.println(new B());
    }

    static aspect Bang {
        abstract String A.getName();
        public String B.getName() { return "B"; }
        public String A.toString() { return getName(); }
    }
}


The crux is in my declaration of A.getName() as package access and B.getName() as public. If they both have identical access modifiers the program runs fine...

Version Info:

Version: 1.1.12
Build id: 20040813151120
AspectJ version: 1.2.0

and:

j2sdk1.4.2_02


Am I missing something obvious or should I submit it to bugzilla?


Thanks,

-phil


_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ajdt-dev


_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ajdt-dev




_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ajdt-dev





Back to the top