Community
Participate
Working Groups
the folowing fails at runtime with a VerifyError. the bug only occurs if the weaved in class is an inner class, the pointcut is a set(* *.*) with the type and field name part left as "*" (a pattern such as "f*" doesn't trigger the bug for instance), the target of the pointcut is bounded to an advice declaration, and the "-1.5" switch is used when calling ajc. public class Bug { class Inner { // works if static private Integer field; void bug() { field = new Integer(0); } } public static void main(String[] args) { new Bug().new Inner().bug(); } } aspect Aspect { before(Object t) : // target(Object) && // works // this(t) && // works target(t) && // fails // set(* Bug.Inner.field) // works // set(Integer Bug.Inner.*) // works // get(* Bug.Inner.*) // works set(* Bug.Inner.*) // fails {} } Exception in thread "main" java.lang.VerifyError: (class: Bug$Inner, method: <init> signature: (LBug;)V) Expecting to find object/array on stack at Bug.main(Bug.java:10)
just a quick note to say... we really appreciate the excellent bug reports that you submit with easily reproducable test cases. You're obviously pushing the new AspectJ support to the limits which is great. What is your project using aspectj for if you don't mind me asking ?
(In reply to comment #1) see "http://www.cs.mcgill.ca/~joerg/sel/research/optima.html" it's a framework for multithreaded programming which allows application programmers to separate their work into (multithreaded) atomic components which get automatically undone if an exception is thrown past its boundary. we decided to use aspectj because we needed to keep track of all the field modifications in order to undo them, but I got carried away and used aspectj all over the place because I feel inter-type declarations allow me to modularize my work better. I am also a big fan of the new syntactic features of java 1.5, which is why I am using your new development branches intead of using abc, the alternative aspectj compiler from my university. unfortunately, pushing the limits of aspectj has led me to discover the limitations of its pointcut syntax. for now, I am bothered by the fact that although we can easily write code around all "get(* *.*)" statements inside "* foo(..)" bodies, I could not figure a way of writing code around all "* foo(..)" executions containing "get(* *.*)" statements. as you may know, more powerful and programmable pointcut languages are being suggested by university folks (for instance see "www.st.informatik.tu-darmstadt.de"), but available implementations don't support my favorite 1.5 extensions, so aspectj still wins; keep up the good work!
for M4
didn't realise it at the time, but pr109124 was a duplicate of this. I've fixed that bug, and just verified that it also fixes the problem reported here, so this is now fixed and you can pick up the fix from the AspectJ download page later on today. Thanks, Adrian. *** This bug has been marked as a duplicate of 109124 ***
