Community
Participate
Working Groups
It would be very nice to allow calling super.method() in an ITD, where the super implementation is itself and ITD. Unfortunately, I don't think it's possible with the current Java bytecode definition. Failing that, the compiler should be consistent and flag an error. Here's the output from a program that compiles then fails at runtime (both with 1.5.0 and the Mar. 28 nightly build): java pkg.Derived Exception in thread "main" java.lang.AbstractMethodError: pkg.Derived$1.ajc$supe rDispatch$pkg_Base$BaseBean$toString()Ljava/lang/String; at pkg.Base.ajc$interMethod$pkg_Base$pkg_Base$BaseBean$describe(Base.aj: 6) at pkg.Derived.ajc$interMethod$pkg_Derived$pkg_Derived$DerivedBean$descr ibe(Derived.aj:9) at pkg.Derived$1.describe(Derived.aj:1) at pkg.Derived.ajc$interMethodDispatch1$pkg_Derived$pkg_Derived$DerivedB ean$describe(Derived.aj) at pkg.Derived.main(Derived.aj:12) Source files: package pkg; import pkg.Base.BaseBean; public aspect Derived { public interface DerivedBean extends BaseBean {} public String DerivedBean.describe() { return "Derived state plus "+super.describe(); } public static void main(String args[]) { new DerivedBean() {}.describe(); } } package pkg; public aspect Base { public interface BaseBean {} public String BaseBean.describe() { return "Base holds "+super.toString(); } }
Hoisting priority - runtime errors are the worst kind of failure.
Not sure what this comment means "I don't think it's possible with the current Java bytecode definition". With a fix in the weaver, this program now compiles and runs fine... The problem is with generating a helper method for the toString() method invoked via BeanBean.describe(). Because the ITDs are on interfaces, when we put the implementation of the describe method on the implementing class ( the anonymous class created here "new DerivedBean() {}.describe();" ) then the subITD is overriding the superITD - we have correctly worked this out, but because the superITD is forgotten, we also forget that it called 'super.toString()' and needed a method generated to support that call. The solution is for an ITD to remember which ITDs it is overriding - that way when the code is eventually generated in the target class, we can see if it was overriding any other ITDs that also needed methods generating.
Great - I'm glad it's possible to support proper inheritance of ITD methods. My comment was just a guess that maybe this wasn't supported because it couldn't be. Thanks for the fix.
ought to get around to this
unsetting the target field which is currently set for something already released