Community
Participate
Working Groups
Created attachment 106516 [details] pre and post instrumentation classes I'm seeing a problem in which aspectj seems to replace the bytecode from one class with the bytecode from another class if the two classes are located in the same directory, but with different names. I've attached a sample here with the original and post instrumentation classes. Util.class contains two functions, reverse() and add() Util-no-add.class is a backup of Util.class and contains only reverse() After instrumentation both classes only contain reverse(). The entire com/ directory is passed in for instrumentation.
java classes are known by their internal name not by their file system name. AspectJ just sees the same class twice and whichever is last is likely to end up on disk I imagine. We don't preserve the input .class name, we recalculate it to be correct based on the type declared within - producing class files that don't run wouldn't seem all that useful. If you don't want the backup woven, change the suffix from .class to something else, then the weaver won't see it.
The way the java classloader works this is a valid scenario, and, although I think it's bad practice, we have seen examples of this at our customer sites. Fixing this outside aspectj is very difficult because right now there is no need for us to go down to the individual file level since aspectj takes jars and directories. Also, we'd need to start looking into the bytecode which we currently don't do as part of our product. It seems like enforcing this internally in aspectj is the right place to do it because anyone using the .jar or directories approach can run into this problem.
You haven't mentioned so far what you would want AspectJ to do - do you want it to error/ignore when it encounters these incorrectly named files? I might be able to put in an xlint that you can configure to error/warn/ignore when this occurs, and the files themselves would be dismissed and never woven, since they could never be loaded. As you say, it is bad practice - shame I may have to change AspectJ to cope with it.
Preferably if it encounters a class whose filename does not match the internal class name it would give a warning and ignore that class since that class would never be loaded by a standard java classloader anyways.
unsetting the target field which is currently set for something already released
