Community
Participate
Working Groups
declare precedence for inter-type declarations appears broken in 1.6... The following compiles correctly in version 1.5.4 (and produces the output "Y.test()" as expected) but the 1.6 and last known good developer builds result in: Z.java:2 [error] The method test() is ambiguous for the type Z public static void main(String[] args) throws Exception { new Z().test(); } 1 error interface X { static aspect IMPL { public void X.test() { System.out.println("X.test()"); } } } interface Y { static aspect IMPL { declare precedence : Y.IMPL, X.IMPL; public void Y.test() { System.out.println("Y.test()"); } } } public class Z implements X, Y { public static void main(String[] args) throws Exception { new Z().test(); } } Note that you may "trick" ajc into compiling this by casting "new Z()" to either X or Y. Doing so will give the same runtime result 1.5.4.
this is due to a rewrite in the 3.3 JDT compiler of the method: Scope.mostSpecificMethodBinding() and due to the use of declare precedence to determine ITD ordering being a rare case (usually), there are no tests for it (*sigh*). The main references to declare precedence throughout the documentation are for determining advice precedence order at a join point when multiple pieces apply and there are many tests for that, it works fine. However, there is a line in the doc: --- Given a potential conflict between inter-type member declarations in different aspects, if one aspect has precedence over the other its declaration will take effect without any conflict notice from compiler. This is true both when the precedence is declared explicitly with declare precedence as well as when when sub-aspects implicitly have precedence over their super-aspect. --- so I am trying to get it to work for 1.6.1. However, given how it worked in 1.5.4, I think it worked by accident rather than by design and will try and do a better job in 1.6.1
I've just reworked the Scope code and fixed this problem. Fix will be in next dev build. Also added some tests (based on your testcase, thanks for that) - so it can't break again.
