aboutsummaryrefslogtreecommitdiffstats
path: root/tests/bugs1612/pr335810
diff options
context:
space:
mode:
authorUri Simchoni <urisimchoni@gmail.com>2024-02-04 12:51:15 +0200
committerAlexander Kriegisch <Alexander@Kriegisch.name>2024-02-08 12:17:55 +0700
commitefef3c0792f521256fc3889744878ead11f8324a (patch)
treeba6209138685e28ff5a07d56ac4d7c90bfae2543 /tests/bugs1612/pr335810
parent5cdff3bf0c7c62d42ab2022e0ac4ed55ef63108a (diff)
downloadaspectj-efef3c0792f521256fc3889744878ead11f8324a.tar.gz
aspectj-efef3c0792f521256fc3889744878ead11f8324a.zip
Use previous weaving result if classes were generated during weaving
A parallel-capable class loader might load the same class multiple times in multiple threads, see https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html. In this scenario, the JVM instrumentation mechanism invokes the AspectJ weaver twice on the same class. In simple weaving scenarios, this would just cause weaving logic to run multiple times and produce the same result for each thread, but if the weaver is generating new classes, it is undesirable to generate those classes multiple times. To avoid this, the generatedClasses map in WeavingAdaptor keeps track of classes for which inner classes were generated and avoids re-weaving them. However, before this change, if a class was found in the generated map, the weaver would return the un-woven bytes, which would cause AspectJ not to work for some of the threads. This change returns the woven bytes instead of re-running weaving. Fixes #279.
Diffstat (limited to 'tests/bugs1612/pr335810')
0 files changed, 0 insertions, 0 deletions