Community
Participate
Working Groups
Hello everybody! The problem was already before but appears again. When I re-weave aspect classes via -inpath option on 2-3d compile I'm getting "Bad WeaverState.Kind: -115" like in 352389 bug. Below is a duplicate description about how I'm getting this error I've been posted upon the 352389 bug. The stackrace of compiler crash also available in my comment under 352389. — I've been delcared my java output as -inpath to handle weaving sub-java languages, like groovy or kotlin, which cannot be accessed in CTW, but with binary weaver only; — This inpath contains already woven aj classes; — Restricting inpath to concrete directory (package) doesn't allow ajc to weave anything; (below more details about this) The aspects that breaks ajc you can find here in my example project: https://github.com/Archinamon/AspectJExampleAndroid/tree/master/app/src/main/aspectj/com/archinamon/xpoint Dunno, am I should crete a separate bug report for this one? I'm trying to restrict ajc binary weaving from passing all files in my output dir, so I walk across all sources, marks aspectj folder and exclude it from inpath directories. I'm adding to inpath only not-common directories with non-aspect binary outputs (java, groovy, etc.). But this behaviour doesn't recognisable by ajc — it doesn't weave my .class files at all if inpath not equals to the common build variant output dir. Hard to describe it, so I'll write simple example: My java output path (android project) is: "/Project/app/build/intermediates/classes/debug/" where 'app' is a sub-module, 'debug' is my build variant. When I'm trying to set inpath to smth different from the path mentioned above, for example: "/Project/app/build/intermediates/classes/debug/com/archinamon/grooid/" where I have groovy compiled code, then ajc not pick up this bytecodes at all. No errors or warnings I didn't get :(
Created attachment 259971 [details] ajc crash log
Hi Eduard, I saw you comment on bug 352389 but I didn't have time to comment until now. Raising a new bug is fine. If I create a test build that includes the patch from 352389, can you try it out? I presume you need it in a maven repo? I tried cloning your project and building it but I don't have the necessary android infrastructure around. It sounds like you don't actually need overweaving, you just need a way to stop it needing to occur. If it isn't weaving anything without including some of your artifacts on the inpath, is that because that is where the aspects are? In which case they would go on the aspectpath. ajc -inpath <kotlin_output_folder>:<groovy_output_folder> -aspectpath:<aspects_to_weave> -d <output_location>
There is a test build with the patch from 352389 in this maven repo: <repository> <id>repo.spring.io</id> <name>SpringSource snapshots</name> <url>http://repo.spring.io/snapshot</url> </repository> called 1.8.9.BUILD-SNAPSHOT, if you want to try it.
Created attachment 260269 [details] ajc crash log Hello, Andrew! Thank's for the snapshot, I've tried it out. Still getting error compiling my project. I'll try to describe all steps I'm doing. 1. I upgraded my aspectjrt and aspectjtools to 1.8.9 snapshot version and made clean on my example project. 2. First build was successful and all aj weavings were done into java and groovy. 3. Then I ran second build (hot-build without cleaning built files) and got ajc crash: Caused by: java.lang.ClassCastException: org.aspectj.apache.bcel.classfile.ConstantFieldref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8 at org.aspectj.apache.bcel.classfile.ConstantPool.getConstantUtf8(ConstantPool.java:276) I've attached new crash log. About your advice to separate the build folders for groovy/kotlin and java to ensure I won't re-pass aspectj code on -inpath — that's good idea, I'll try to make something around it, but that's not a "good practice" because I'll need to redefine output path for a plugin I'm not a developer in (I mean groovy/etc. language plugins). Although I can't define exactly path to weave on -inpath. If I try to define some concrete folder inside build dir, not the build dir itself — ajc not weave on -inpath at all. :(
The latest problem does seem to be something different though, so you are past the weaver state kind problem. The new problem looks to me like something is modifying the class file between aspectJ creating it and then getting another look at it. AspectJ does currently encode some constant pool references in attributes. Caused by: java.lang.ClassCastException: org.aspectj.apache.bcel.classfile.ConstantFieldref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8 at org.aspectj.apache.bcel.classfile.ConstantPool.getConstantUtf8(ConstantPool.java:276) at org.aspectj.weaver.bcel.BcelConstantPoolReader.readUtf8(BcelConstantPoolReader.java:31) at org.aspectj.weaver.VersionedDataInputStream.readUtf8(VersionedDataInputStream.java:61) at org.aspectj.weaver.VersionedDataInputStream.readSignatureAsUnresolvedType(VersionedDataInputStream.java:81) In this case it looks like we are reading a signature and expecting to find it as a Utf8 at a particular entry in the constant pool. But something has messed with the constant pool and it is no longer a Utf8, it is a ConstantFieldRef. In these situations you either need to avoid modifying the classfile in between AspectJ creating it and subsequently working on it again, or you have to get the thing you are using to modify it to avoid damaging the existing constantpool. These tools can add to it but not re-order or otherwise optimize the existing entries since that can damage anything using encoded attribute references. Maybe the tool you are using offers a flag to achieve that. Although maybe the class file name is a clue, is retrolambda being used? It is possible that it cannot avoid removing entries if trying to convert a class file for one JVM level to another.
Yes, I'm using retrolambda and have to make ajc build compatible with it. But strange thing is that ajc pass before retrolambda task. And conceptually it shouldn't affect aj classes before the ajc task done it work. Can something else be affected in ajc before inpath would process?
Created attachment 260322 [details] ajc log Now I'm applying inpath weaving only on bytecode that never was proceed by retrolambda, but got an old error with bad WeaverState.Kind :( I think about walk through the files and implicitly delete all aspectj bytecode from output dir before ajc runs over bytecode.
