Community
Participate
Working Groups
java.lang.ArrayIndexOutOfBoundsException: 3 Unfortunately I can't provide much more information, please see the attached compiler dump.
Created attachment 16822 [details] Compiler dump
Created attachment 16823 [details] 1.5.0 M1 dump without recompiling dependant projects
Created attachment 16824 [details] 1.5.0 M1 dump after recompiling dependant projects with 1.5.0 M1
btw, the warnings in the first dump like this one: [warning] can not resolve this member: void com.netvisor.ttm.ui.HpsdCSVTask. addUserMessage(java.lang.String, int) [Xlint:unresolvableMember] are false warnings as far as i can understand what's going on. UserMessageCollectorMixin is defined in a jar file which is on the classpath, not aspectpath. therefore i have an aspect in the project like this: public abstract aspect UserMessageCollectorMixin extends com.netvisor.common. UserMessageCollectorMixin { declare parents: (CSVTaskBase) implements UserMessageCollector; declare precedence: UserMessageCollectorMixin; } that "brings in" the aspect into the waeving. i had these warnings for a long time, so i doubt it's closely related.
it IS connected to the warnings: it tires to issue a warning at an empty line, and while trimming the empty line goes out of the array... i've modified the code like this around the lines where the exception happens: while ((((c = extract[trimLeftIndex++]) == TAB) || (c == SPACE)) && trimLeftIndex < extract.length) { }; if (trimLeftIndex >= extract.length) return new String(extract) + "\n"; //$NON-NLS-2$ //$NON-NLS-1$ unfortunately the warnings are still bugous. i've rearranged the build process to put the jar containing UserMessageCollectorMixin into the aspectpath, but i still get the warnings...
Created attachment 16825 [details] UserMessageCollector.java
Created attachment 16826 [details] UserMessageCollectorMixin.java
You could turn off the xlint warnings until I fix the bug, simplest way is: ajc -Xlint:ignore <.....> (that might be xlint="ignore" in an ant build.xml). === Those warnings are telling you that ajc couldn't resolve a member, you *may or may not* be interested in the warning depending on whether the advice you have written was intended to capture references to those members. From some write up I put into bug 59596: === An unresolvable member is a member (method declaration) we have found in some inheritance hierarchy (its on some interface somewhere) that has no implementation within that hierarchy, apparently due to the use of abstract classes that provide no implementation for it. Without the concrete implementation it can't be successfully 'resolved' and so we can't match on it. ==== I've seen more unresolvablemember issues recently as we have moved to partially supporting 1.5. For example if some piece of code uses an API that only exists on 1.5 (maybe Integer.valueOf(int) which was added in 1.5 for autoboxing) and then AspectJ is asked to weave it, you are likely to get unresolvableMember errors for calls to those members - I'm not saying this is what is happening here but it is one cause of unresolvablemember problems. Are you relying on autoboxing in your app? The possible solution is to put the rt.jar from a 1.5 JVM on your classpath ahead of everything else (effectively running the AspectJ compiler on a 1.5 VM - I can't vouch that this will work as we haven't done much testing of it yet). It may also help to ensure you have 'debug="yes"' on the javac call to compile your source code as the default is no and it looks like we are blowing up whilst accessing some source context to put out a sensible message. However, obviously there is something to fix, so I'll do that soon as I can.
thanks for the quick answer, Andy! since then i've compiled an 1.2.1 with my patch in it which avoids a crash, so don't worry about this more then appropiate. an idea: errors in nonessential parts of the system (like messaging the user) should only generate a warning and go on with the execution. about the warning: i don't use 1.5 vm. this warning was lingering around for a long time now, pre 1.5. please note that i use the aspect in question in other projects in similar setups, but the warnings appear only in this project. also note that the aspect is privileged, so it should be woven before the others. well, i have other privileged aspects... so it would be helpful if the warning message contained what aspect is being woven while the method is not found, so i could take a look at declare precedence stuff. thanks, and marry christmas! :)
I meant declare precedence, not privileged. Bah, too much work...
oops, this patch should have been integrated long ago. scheduling for aj5m3...
I'm hit by this bug again as we are moving to java 1.5. Could you please add at least the check not to access the array out of bounds? I've tried xlint="ignore" but id didn't help... I know I could compile a locally patched version, but I've already driven mad my collegues with having custom versions of all kind of OSS stuff... :)
I've just integrated your patch - it will appear in a dev build shortly. sorry for the long delay!! Out of interest, with your patch in place, what kind of strange messages do you see for these empty lines? Is there any way you can paste a sample of them into here?
Patch integrated. See latest dev build from http://eclipse.org/aspectj/downloads.php
