[
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