Community
Participate
Working Groups
During a refactoring with AspectJ i encountered a runtime Exception when writing an around advice for "new Integer" within an Interface. When disabling the advice, there's no exception. Originally the interface invoked some kind of pooling functionality that should be invoked by the aspect after the refactoring. The original direct invocation also did not cause an exception. I isolated the problem as follows: -------------- interface Constants -------------- public interface Constants { int ALL = 3; Integer INTEGER_ALL = new Integer(ALL); } -------------- class ConstantsTestClass -------------- public class ConstantsTestClass implements Constants { public ConstantsTestClass() {} public void printInt() { System.out.println(ALL); } } -------------- aspect ConstantsAspect -------------- public aspect ConstantsAspect { Integer around(int val) : call (java.lang.Integer.new(int)) && !within(ConstantsAspect) && args (val) { return new Integer(val); } } ----------- class Main ----------- public class Main { public Main() {} public static void main(String[] args) { ConstantsTestClass tc = new ConstantsTestClass(); tc.printInt(); } } ------------ resulting exception during runtime ------------ Exception in thread "main" java.lang.ClassFormatError: Constants (Illegal method modifiers: 0x1A) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at Main.main(Main.java:20)
thanks for the clear testcase - I've recreated this on the HEAD version of AspectJ.
and i've recreated it all the way back to AspectJ1.2.1 - looks like a scenario causing us to stick method bodies into an interface...
I actually ran into this over the weekend. Puzzled me to no end until I search for a bug. Any progress on this or a work-around?
worst case we must be able to detect we are going to do something wrong and report an error (compiler limitation) at compile time rather than exploding at runtime.
The 'compiler limitation' solution is now available in AspectJ1.6.3 (work was done under bug 163005) - we will skip weaving the join point, and produce an xlint message to indicate the situation. The code here now says: [warning] The joinpoint 'constructor-call(void java.lang.Integer.<init>(int))' cannot be advised and is being skipped as the compiler implementation will lead to creation of methods with bodies in an interface (compiler limitation) [Xlint:cannotAdviseJoinpointInInterfaceWithAroundAdvice] Integer INTEGER_ALL = new Integer(ALL); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
