Bugzilla – Full Text Bug Listing
| Summary: | StringIndexOutOfBoundsException during compilation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] AspectJ | Reporter: | Neale Upstone <neale> | ||||||
| Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> | ||||||
| Status: | NEW --- | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P2 | CC: | aclement, dmorari | ||||||
| Version: | 1.6.10 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Neale Upstone
Created attachment 185694 [details]
ajcore dump
I don't know why, but I'm having real trouble recreating this problem. I have 1.6.10, I have spring-aspects-3.0.3.RELEASE.jar. The index of out bounds exception indicates there is a typename with 0 length in the jar. Of course, I am making an assumption that it is getting the AnnotationBeanConfigurerAspect from the spring-aspects jar, but it should be. Although I couldn't recreate this issue, I have uncovered an error with attribute serialization whilst working on another bug, which *could* be related. This is fixed in the latest dev build: http://eclipse.org/aspectj/downloads.php If you have a moment, I'd be really interested in you trying out the failing scenario with that weaver. thanks. If you don't have time to grab a jar and try it, I'll probably be putting a 1.6.11.M2 out shortly with the change in it. Thanks Andy. I'll give the dev build a go next week when I'm back (from skiing :-) Back, but gonna wait for the milestone as rather pushed for time. can you attach an updated stack trace with 1.6.11.m2, in case it is subtly different. Created attachment 189782 [details]
1.6.11.M2 stack dump
unsetting the target field which is currently set for something already released Andy, As I've not seen this since, I think it would make sense to close as "works for me". I don't even know what codebase it was that generated that issue now. I'm not sure this is the same bug, though the stacktrace looks quite similar.
Using AspectJ 1.8.1, Java 8.
I get the following exception when class having this method
public String getString() {
Optional<String> dummy = Optional.of("Just a dummy optional");
return dummy.orElseThrow(() -> {
return new RuntimeException();
});
}
is woven:
[AppClassLoader@58644d46] abort trouble in:
public class com.foo.Bar extends java.lang.Object:
// Bytecode of the class
Aug 19, 2014 4:28:51 PM org.aspectj.weaver.tools.Jdk14Trace error
SEVERE: com/inthergroup/aspect/retry/config/Parser
java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:646)
at org.aspectj.weaver.UnresolvedType.forSignature(UnresolvedType.java:383)
While this works fine :
public String getString() {
Optional<String> dummy = Optional.of("Just a dummy optional");
return dummy.orElseThrow(RuntimeException::new);
}
Hey Dan,
I'm trying to recreate that without much luck, I wrapped up your snippet with an aspect but I can't make it fail (at AspectJ 1.8.0/1.8.1 or 1.8.2):
=== Code.java ===
import java.util.*;
public class Code {
public String getString() {
Optional<String> dummy = Optional.of("Just a dummy optional");
return dummy.orElseThrow(() -> {
return new RuntimeException();
});
}
}
aspect X {
before(): within(!X) {System.out.println(thisJoinPoint);}
}
===
Can you distill it into a small failing example? I'm not sure what kind of advice or pointcut you are having trouble with.
Hi Andrew,
The preceding example is not a part of an aspect source code : this is a simple class; I don't have any aspect matching this class - theoretically it should remain untouched.
The only one thing - Code.java class belongs to a package configured to be scanned in the aop.xml.
<aspectj>
<weaver options="-showWeaveInfo
-Xset:overWeaving=true">
<include within="com.package.where.the.class.is..*" />
</weaver>
<aspects>
</aspects>
AspectJ produces that error in output during the loadtime weaving, while compilation using aspectj-maven-plugin doesn't have issues.
After error is printed, it skips this class and moves forward.
I think it happens when AspectJ attempts to parse bytecode of that class, and guess this logic doesn't depend on aspects defined.
If I'm mistaken and what type of pointcuts/advices we have matters, let me know (I will have a look into sources, haven't seen them yet).
Is there any chance you could share with me (privately?) the compiled class in question so I can take a look at the bytecode? |