diff options
author | Uri Simchoni <urisimchoni@gmail.com> | 2024-02-04 12:51:15 +0200 |
---|---|---|
committer | Alexander Kriegisch <Alexander@Kriegisch.name> | 2024-02-08 12:17:55 +0700 |
commit | efef3c0792f521256fc3889744878ead11f8324a (patch) | |
tree | ba6209138685e28ff5a07d56ac4d7c90bfae2543 /tests/bugs1612/pr335810 | |
parent | 5cdff3bf0c7c62d42ab2022e0ac4ed55ef63108a (diff) | |
download | aspectj-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