Community
Participate
Working Groups
[This was first pointed out by Aske Christensen (aske@brics.dk), and the description below is due to him.] Java compiles a method invocation into an invocation of the method with the same name whose parameter types most closely match the declared types of the arguments. This can cause different method call signatures to be generated depending on whether the Java class was compiled separately or together with an aspect. It's not really a compiler bug, but the docs should warn of this behaviour. Consider this program: public class MethodMatch { public static void main(String[] args) { foo((Object)"Object"); foo("String"); } public static void foo(Object o) { System.out.println("An object: " + o); } } public aspect NewFoo { public static void MethodMatch.foo(String s) { System.out.println("A string: " + s); } after(): execution(void main(*)) { System.out.println("Woven"); } } If we just compile the MethodMatch class by itself without weaving any aspects, we get the output: An object: Object An object: String If we now weave the NewFoo aspect into the MethodMatch class file, we get: An object: Object An object: String Woven However, if we compile MethodMatch and NewFoo together, we get: An object: Object A string: String Woven
This is a doc bug as stated by the bug report itself. I see this as a classic issue of separate compilation. If I add a class SuperMethodMatch and declare MethodMatch extends SuperMethodMatch, then I can get this same behavior in pure Java. All that I have to do is add the foo (String) method to SuperMethodMatch and only recompile the super class without recompiling the implementors. Our docs do need a better description of the effects of different kinds of separate compilation in AspectJ; however, I don't think this is too radically different from the issues of separate compilation in Java.
Changing this to a P4 enhancement; I'm not going to be able to finesse the language a section like this must have for 1.2.1. In general I am not convinced that typical users will need a warning that binary compatibility is an issue. And enough of a specification of the binary compatibility issues with AspectJ (though there aren't greatly more than those in JLS 13) to satisfy language folks like myself will take more dedicated hours than I have right now. So priority downgraded due to too low payoff/work.
I'm assigning this to adrian as a placeholder, but I have a feeling this should be copied to a "maybe, someday" list and marked resolved/wontfix or resolved/later to get it out of the bug list
As per Erik's comment, no "typical users" have reported any issue with this in the last year, so I'm moving to LATER as we have no immediate plans to update the docs on this matter at this point in time.
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
