Name annotation vs native style aspects uniformly in github_128 tests
Trying to find the difference between byte code generated by AJC for
functionally identical annotation vs native style aspect, I move the
aspects into subdirectories in order to be able to name them
identically. This way, when decompiling them with javap or Fernflower it
is easier to diff them later.
Why the decompilation? Because for the thread pool testing scenario
native syntax passes while annotation syntax fails. I.e., we need to
find the difference. That can be done by reading source code, if you
know where to look, or by starting with reverse engineering in order to
first understand more and look at the code later.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Expand "asynchronous proceed for nested around-advice" to 4 scenarios:
1. @AspectJ syntax, threads created inside advice code
2. @AspectJ syntax, submit runnable to thread pool
3. native syntax, threads created inside advice code
4. native syntax, submit runnable to thread pool
Scenarios 1, 3 and 4 are passing, while 2 is failing.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Regression test for #125: Bugs198Tests.testGitHub_125
This test fails when run against AspectJ 1.9.8 with JDT Core 1.9.8.RC3.
It passes when using the latest JDT Core 1.9.9-SNAPSHOT. It sets system
property 'org.aspectj.weaver.openarchives=20', provoking open classpath
JAR file exhaustion when compiling a simple class with AJC, i.e. JARs
are being forcibly closed and automatically re-opened, as soon as they
are needed. Before the JDT Core bugfix, this test causes:
java.lang.NullPointerException
at ....compiler.batch.ClasspathJmod.getModulesDeclaringPackage
With the bugfix incorporated into AspectJ Tools, the problem is gone.
Note: New test dependency 'io.github.bmuskalla:scoped-system-properties'
helps to test compilation with the temporarily changed global system
property in isolation, saving the environment in a thread-local
variable and later cleanly restoring the original values again. If we
ever switch to parallel test execution, this would otherwise influence
other tests and potentially cause weird side effects. Better safe than
sorry.
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
Fix annotation style support for if(true) and if(false)
The documentation specifies annotation style pointcuts
can use if(false) or if(true) and not require a boolean
return value and body for the @Pointcut annotated
method but it doesn't work without this change to validation
that recognizes the situation.
Fixes #115
Alexander Kriegisch
Andy Clement