Community
Participate
Working Groups
The following program is accepted by ajc -1.5: public aspect AbstractITD { public abstract Object A.foo(); public static void main(String[] args) { A a = new B(); System.out.println(a.foo()); } } abstract class A {} class B extends A { public Integer foo() { return new Integer(42); } } But it does not put in the necessary bridge method, so the program throws an AbstractMethodError at runtime: Exception in thread "main" java.lang.AbstractMethodError: A.foo()Ljava/lang/Object; at AbstractITD.ajc$interMethodDispatch1$AbstractITD$A$foo(AbstractITD.java) at AbstractITD.main(AbstractITD.java:7) ajc without -1.5 does not reject the program. I guess it should, since covariant return type is a 1.5 feature. Also, if the @Override annotation is put on the method in B, ajc -1.5 complains, even though the method does override a superclass method.
Raising priority for compiler course starting 28/8. Will give it a shot - itds and generics are the one area we're held up on for M3 at the moment, proving quite tricky to get everything nailed....
@Override problem is now fixed. And just collecting notes in this bug...Some ITD variants work and the bridge methods are created, for example: public class Super2 { public Object m() { return null;} } public class Sub2 extends Super2 { } public aspect X2 { public Integer Sub2.m() {return new Integer(42);} } produces a version of Sub2 that looks like this: public class Sub2 extends Super2{ public Sub2(); public java.lang.Object m(); public java.lang.Integer m(); } we get that free from the JDT compiler as it knows ITDs are around. I'm not sure why it has trouble if the ITD is on the supertype. and we'll also need to take binary weaving/separate compilation into account - so we can't always rely on the JDT compiler to generate the necessary methods :(
I've fixed this. We now generate the bridge methods you would expect. I haven't explored the space with testcases tho - so I wouldn't be surprised if there are other problems lurking. The dev build will appear in a little while - in the meantime, you can try this special build I've just created for another user that happens to also contain this fix: http://download.eclipse.org/technology/aspectj/dev/aspectj-PR107784.jar What I haven't fixed/checked is the policing of using covariant features when not using 1.5 mode - will look at that now.
Ok, I checked the final problem and you do get an error. This program public aspect pr91381_2 { public abstract Object A.foo(); public static void main(String[] args) { A a = new B(); System.out.println(a.foo()); } } abstract class A { } class B extends A { public Integer foo() { return new Integer(42); } } reports: [error 1] error at public Integer foo() { return new Integer(42); } ^^ C:\temp\ajcSandbox\ajcTest25015.tmp\pr91381_2.aj:15:0::0 The return type is incompatible with A.foo() will close the bug when the build is available.
build available - all 3 issues reported have been fixed.
