Fix PointcutRewriterTest, add LogicalPointcutStructure test helper class
After WildTypePattern.hashCode was fixed in the previous commit,
PointcutRewriterTest started failing, because in many places it was
falsely relying on a specific order of hash codes, which cannot be
guaranteed, especially since more instance fields are part of the hash
code now in accordance with 'equals'.
The new test helper class LogicalPointcutStructure is able to recognise
chained '&&' and '||' pointcuts of the same logical nesting level,
un-nesting them from the actual pointcut structure and making them
comparable, disregarding their order. I.e., something like
((A && B) && C) && D
is actually recognised to logically be
A && B && C && D
and equivalent to e.g. either of
D && B && A && C
A && B && D && C
C && A && D && B
This helps to compare rewritten pointcuts, as long as their logical
structure has not been altered.
Relates to #24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
WildTypePattern: fix hashCode and toString methods
Especially 'hashCode' did not correspond to 'equals', disregarding
several fields, array dimension information being only one of them. This
led to parts of pointcuts being ignored, because they were regarded as
duplicates. Example:
execution(Foo* *(..)) && !execution(Foo*[] *(..))
Here, the negated pattern was falsely regarded as equal to the first
pattern, leading to an "A && !A" situation, i.e. no match at all.
Furthermore, 'toString' did not print array strings, i.e. instead of
"Foo*[][]" something like "Foo*" was printed. This false information was
also present in annotations generated by the weaver.
FuzzilyMatchingAspect was adjusted to actually match exactly once, as
expected, for the "Foo*" return types, i.e. exclusions for the array
return types have been added.
Relates to #24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Handle one- and multi-dimensional array return types correctly
Fixes https://github.com/eclipse/org.aspectj/issues/24, both the array
return type matching as such as well as matching dimensionality patterns
correctly. E.g., 'Foo*[]' is not the same as 'Foo*[][]'. This also works
correctly in combination with asterisks, even for primitive types, i.e.
'in*[][]' correctly matches a 2-dimensional array of 'int'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Simplify if-else in WildTypePattern.matchesExactlyByName
A simple boolean condition is enough.
Loosely relates to https://github.com/eclipse/org.aspectj/issues/24, but
actually it is just drive-by cosmetics.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The method falsely determined that a one-dimensional array was not an
array due to a one-off bug.
Relates to https://github.com/eclipse/org.aspectj/issues/24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This commit is a follow-up for 65f1ec72. The SOURCE retention case is
documented now and considered in a few more call sites. The
previously already similar code structures in
- DeclareAnnotation.ensureAnnotationDiscovered,
- DeclareAnnotation.getAnnotationType
have both been streamlined and still remain logically in sync.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix #366085 concerning declared annotations with source retention
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=366085.
See https://stackoverflow.com/q/74618269/1082681.
The issue described in the Bugzilla issue is about 'declare @type', but
similar issues also existed for 'declare @field', 'declare @method',
'declare @constructor'. This fix is rather superficial and leaves
things to be desired, because it is rather hacky and simply ignores
errors source retention annotation declarations during weaving. A better
fix would drop the corresponding declarations while parsing and also
issue compiler warnings in each case.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This fixes:
- negating annotation style if() pointcuts doesn't work
- annotation style if() pointcut not able to use a binding
that is not exposed
Fixes #120,#122
Methods Integer.parseInt/Boolean.parseBoolean should be preferred over Integer.valueOf/Boolean.valueOf/ if final result is primitive.
They are generally faster and generate less garbage.
Trailing whitespaces are useless. Most of code-styles forbids them. Most of editors always trim them on save.
I propose to clean up project from trailing whitespaces in all java files at once.
This is a bugfix release, reverting the essential parts of commit
f70aeb5e, because it causes AspectJ Maven integration tests using
javadoc to fail on JDK 8.
See commit discussion on
https://github.com/eclipse/org.aspectj/commit/f70aeb5e#commitcomment-51417353
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Before, we used 1.9.7.BUILD-SNAPSHOT, which according to Andy Clement
was originally an intent across a group of Spring projects he was
involved in, to ensure that SNAPSHOTS were sorted alphabetically ahead
of MILESTONEs and ahead of RCs.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove redundant 'name' and 'packaging' tags from POMs
If 'name' is identical to 'artifactId' and 'packaging' has the default
value 'jar', we can just remove those tags from the POM.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch
Andrey Turbanov
Andy Clement