Community
Participate
Working Groups
java.lang.NullPointerException at org.aspectj.weaver.MemberImpl.getModifiers(MemberImpl.java:526) at org.aspectj.weaver.MemberImpl.getMethodSignatureString(MemberImpl.java:824) at org.aspectj.weaver.MemberImpl.getSignatureString(MemberImpl.java:753) at org.aspectj.weaver.bcel.LazyClassGen.initializeTjp(LazyClassGen.java:1039) at org.aspectj.weaver.bcel.LazyClassGen.initializeAllTjps(LazyClassGen.java:1016) at org.aspectj.weaver.bcel.LazyClassGen.addAjcInitializers(LazyClassGen.java:964) at org.aspectj.weaver.bcel.LazyClassGen.writeBack(LazyClassGen.java:502) at org.aspectj.weaver.bcel.LazyClassGen.getJavaClassBytesIncludingReweavable(LazyClassGen.java:652) at org.aspectj.weaver.bcel.BcelWeaver.getClassFilesFor(BcelWeaver.java:1337) at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1309) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1127) at org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:284) at org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:212) at org.aspectj.weaver.loadtime.WeavingURLClassLoader.defineClass(WeavingURLClassLoader.java:125) at org.aspectj.weaver.ExtensibleURLClassLoader.defineClass(ExtensibleURLClassLoader.java:80) at org.aspectj.weaver.ExtensibleURLClassLoader.findClass(ExtensibleURLClassLoader.java:46) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) Exception in thread "main" public aspect JoinPointTraceAspect { private int _callDepth = -1; pointcut tracePoints() : !within(JoinPointTraceAspect); before() : tracePoints() { _callDepth++; print("Before", thisJoinPoint); } after() : tracePoints() { print("After", thisJoinPoint); _callDepth--; } private void print(String prefix, Object message) { for(int i = 0, spaces = _callDepth * 2; i < spaces; i++) { System.out.print(" "); } System.out.println(prefix + ": " + message); } } aspect EdtRuleChecker { private boolean isStressChecking = true; public pointcut anySwingMethods(JComponent c): target(c) && call(* *(..)); public pointcut threadSafeMethods(): call(* repaint(..)) || call(* revalidate()) || call(* invalidate()) || call(* getListeners(..)) || call(* add*Listener(..)) || call(* remove*Listener(..)); //calls of any JComponent method, including subclasses before(JComponent c): anySwingMethods(c) && !threadSafeMethods() && !within(EdtRuleChecker) { if(!SwingUtilities.isEventDispatchThread() && (isStressChecking || c.isShowing())) { System.err.println(thisJoinPoint.getSourceLocation()); System.err.println(thisJoinPoint.getSignature()); System.err.println(); } } //calls of any JComponent constructor, including subclasses before(): call(JComponent+.new(..)) { if (isStressChecking && !SwingUtilities.isEventDispatchThread()) { System.err.println(thisJoinPoint.getSourceLocation()); System.err.println(thisJoinPoint.getSignature() + " *constructor*"); System.err.println(); } } } Running with SwingSet2.
Passing over to compiler
I've used your two aspects and am weaving them into SwingSet2.jar but have unfortunately been unable to reproduce your problem. Could you provide more details about your setup? Which versions of AJDT and SwingSet2 are you using? Thanks, Helen
Through code inspection and a simple testcase (which doesn't recreate the problem, just allows me to work out the steps taken) it looks like the NPE is caused because we're trying to resolve a Member whose declaring type doesn't have (or we believe doesn't have) a resolved type with the same name or signature.
I've managed to recreate this NPE if the SwingSet2.jar which I have on my inpath is from a 1.5 sdk and the project which contains the provided aspects is being built with a 1.3 sdk. I therefore believe this bug is caused by a mis-match in versions and am closing this bug as "invalid". Please reopen if you're still seeing the NPE and do not have a mis-match of versions.
Helen, I'm sorry I didn't provide more details and you had to do so much investigation. Thanks for looking into this. Are you sure throwing an NPE is the best that can be done? If the null is from probable tool misuse, wouldn't it be better to check for null and throw a more descriptive exception instead? The bug report almost certainly comes from pilot error on my part. When confronted with the stack trace, that wasn't at all obvious to me. Thanks, Curt
Yes, I see your point :-) We do have an XLint option "Unresolvable Member" which we could use in this case (since the problem is that we're looking at a member and are unable to resolve it). If this was implemented then in your case you would have got a warning message of the form "cannot resolve this member: <member name>" rather than an NPE. Would this have been helpful to you? (note that this xlint option is set to warning by default)
"cannot resolve this member:<member name>" would be better than an NPE. To me, that still means that I need to know more about AspectJ than I'm likely to in order to understand the message. I'm a new user, so I need more hand holding than most. I really like this Ant message (see below) that not only tells me what the problem is, but what might be causing it and what might fix it. It is much too verbose for an exception message, but such a message could be logged. The message itself could contain the core info and suggest consulting the log for further details. While there is still room for improvement, this criticism is much too harsh: http://cafe.elharo.com/java/errormsg/ I think the goals should be: 1) the developer should be able to fix the problem from the message and stack trace 2) failing that, someone on the AspectJ team should be able to understand the problem from the message and stack trace Thanks, Curt Ant message in question: BUILD FAILED /blah.../build.xml:51: Could not create task or type of type: junit. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: - You have misspelt 'junit'. Fix: check your spelling. - The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. - The task is an Ant optional task and the JAR file and/or libraries implementing the functionality were not found at the time you yourself built your installation of Ant from the Ant sources. Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the task and make sure it contains more than merely a META-INF/MANIFEST.MF. If all it contains is the manifest, then rebuild Ant with the needed libraries present in ${ant.home}/lib/optional/ , or alternatively, download a pre-built release version from apache.org - The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant - The task is not an Ant core or optional task and needs to be declared using <taskdef>. - You are attempting to use a task defined using <presetdef> or <macrodef> but have spelt wrong or not defined it at the point of use Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug.
Reopening this bug as we shouldn't NPE. At the very least the "unresolved member" warning should be thrown.
Looking into this more closely, the same NPE occurs under the following conditions: 1. Type T1 is available when type T2 is compiled into a jar file. Type T2 has a reference to T1. When compiling/weaving the contents of a project which has the jar file on it's inpath but doesn't have access to T1 we get the NPE 2. Type T1 contains a member m when type T2 is compiled. Type T2 calls this member. When compiling/weaving the contents of a project which has the jar file on it's inpath and a version of T1 which doesn't contain m we get the NPE. In both these cases the NPE only happens when an aspect advises an aspect which advises the use of the type contained in the jar file. There should be two different solutions to these situations. In the first case we should report a cantFindType whereas in the second we should report an unresolvableMember.
Created attachment 51417 [details] zip file containing proposed fix and testcases The attached zip file contains the following: 1. pr149908-weaver.txt: Apply to the weaver project. This patch contains the fix proposed in comment #9 2. pr149908-tests.txt: Apply to the tests project. This patch contains test programs for the two scenarios described in comment #9 3. simple.jar: Place in the tests\bugs153\pr149908 directory. This is used in the test for scenario 1 in comment #9. 4. stringBuilder.jar: Place in the tests\bugs153\pr149908 directory. This is used in the test for scenario 2 in comment #9.
patches committed. slightly nervous about adding 2 more booleans to every member in the system.
fix is available in latest aj dev build, therefore closing as fixed. iplog
