Revert WeavingAdaptor generated class map optimisation
This was introduced in commit 8a4aa03845 of PR #278 contribution as part
of the #279 fix. The contributor thought that the generated closure
class entries were never used, but in fact AJDT class OSGiWeavingAdaptor
relies on the presence of those entries.
To the best of my present knowledge, it looks as if this change was the
root cause of https://github.com/eclipse-aspectj/ajdt/issues/57.
Therefore, I reverted it, simultaneously refactoring Iterator::remove
usage to delete entries from the map to Collection::removeIf.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Raise ClassLoaderWeavingAdaptor::defineClass visibility to protected
Relates to https://github.com/eclipse-aspectj/ajdt/issues/57 and it a
precondition for refactoring phase 2 of child class
OSGiWeavingAdaptor::defineClass, which can now directly call the super
methods instead of using reflection.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
1. Write SAME_BYTES to cacheMap when woven bytes are null
2. Fix TODO in SimpleCache::getAndInitialize, using Optional to help
indicate cache hit for unwoven class
3. Improve test coverage (cache miss, cache hit for unwoven class)
Relates to #285.
Co-authored-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Signed-off-by: KimmingLau <294001791@qq.com>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Store only weaved class names in the generatedClasses map
The generatedClasses map contained both keys of woven classes that had
generated classes associated with them, and the keys of the generated
classes themselves. It seems like this map is never consulted for the
generated class key - the generated class is generated from within the
context of woven class loading / retransformation, and thus no transform
event is generated for it by the JVM. Because of that, we do not need to
guard against re-weaving it. Other uses of generatedClasses map are for
full/empty tests, where the woven class key is sufficient. This change
simplifies deletion of a class because we do not have to look for its
associated generated classes.
Relates to #279.
Weaver returns null instead of original bytes for unwoven classes
This change makes sense independently of #277, but also enables using
- cp "my.jar;aspectjweaver.jar"
-XX:+AllowArchivingWithJavaAgent
-javaagent:aspectjweaver.jar
while creating a CDS archive. Afterward, the application can be run in
its woven state from the CDS archive even without '-javaagent', because
the byte code was archived in its woven state ("poor man's AJC"). See
https://github.com/eclipse-aspectj/aspectj/issues/277#issuecomment-1931142753
for details.
Fixes #277.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe
instances and method handles pointing to their 'defineClass' methods.
Those now work universally on JDKs 8-21. In older JDKs, the method used
to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe.
It is challenging to fetch instances, especially as reflection
protection and module boundaries have been increased in the JDK
progressively. But finally, a solution was adapted from Byte Buddy (BB).
Kudos to BB author Rafael Winterhalter. The previous solution to use
ClassLoader::defineClass and require '--add-opens' is no longer
necessary for the first time since it became necessary in AspectJ 1.9.7
with Java 16 support.
Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm
was used before. Maybe that is too many places, but no worse than before.
Add missing dependency on loadtime to aspectjweaver. This kept a build
like "mvn install -am -pl aspectjweaver" from picking up changed
loadtime classes.
Fixes #117.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In two places, the documentation now contains this text:
"Since AspectJ 1.9.7, the obsolete Oracle/BEA JRockit agent is no longer
part of AspectJ. JRockit JDK never supported Java versions higher than
1.6. Several JRockit JVM features are now part of HotSpot and tools like
Mission Control available for OpenJDK and Oracle JDK."
The decision to drop JRockit support was made during a discussion
between Alexander Kriegisch and Andy Clement:
Andy Clement wrote on 26 Mar 2021:
> Yes I think so.
>
>
> Alexander Kriegisch wrote on 26 Mar 2021:
>
>> https://en.wikipedia.org/wiki/JRockit
>>
>> Can we get rid of that? AspectJ requires Java 8, JRockit never
>> supported more than Java 6.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
There are two styles to convert a collection to an array: either using a pre-sized array (like c.toArray(new String[c.size()])) or using an empty array (like c.toArray(new String[0]).
In older Java versions using pre-sized array was recommended, as the reflection call which is necessary to create an array of proper size was quite slow. However since late updates of OpenJDK 6 this call was intrinsified, making the performance of the empty array version the same and sometimes even better, compared to the pre-sized version. Also passing pre-sized array is dangerous for a concurrent or synchronized collection as a data race is possible between the size and toArray call which may result in extra nulls at the end of the array, if the collection was concurrently shrunk during the operation.
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
'String.indexOf()' expression is replaceable with 'contains()'
Reports any String.indexOf() expressions which can be replaced with a call to the String.contains() method available in Java 5 and newer.
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Reports for loops which iterate over collections or arrays, and can be replaced with an enhanced for loop (i.e. the foreach iteration syntax).
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Alexander Kriegisch
KimmingLau
Uri Simchoni
Andrey Turbanov
Jerry James
Andy Clement
Lars Grefer