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>
AtAjLTWTests: 4 test cases switched to 'useFullLTW' mode
After the Java 18 JDT Core upgrade, some LTW tests are failing and
have to be switched from in-process to full LTW mode due to them now
obviously calling some code paths which need '--add-opens'.
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>
Move some tests from Ajc198TestsJava to Bugs198Tests
They were accidentally stored in thw wrong test class, not just because
they are bug regression tests, not 1.9.8 features, but also because they
are meant to work on Java 5+, not on Java 17+ like the ones in
Ajc198TestsJava.
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
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.
The test worked on my local workstation with German locale, but not on
GitHub with English locale.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Update ECJ version, activate Java 17 preview features tests
After JDT Core (ECJ) was updated to the final Java 17 feature set, the
tests now pass as expected.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Fix one fault sanity test configuration
- Deactivate Java 16 preview tests (no longer supported by Java 17
compiler)
- Test sealed classes as final on Java 17 (no longer preview)
- Add tests for JEP 406, pattern matching for switch (preview). At
present, the beta 17 branch of JDT Core does not handle the tested
features and expected compile errors correctly yet, so I had to
temporarily deactivate test execution, only printing TODO messages.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Refactor AnnoBinding test class used by Ajc1612Tests some more
Improve improved general logging, error messages, variable naming and
indentation, making the code of class AnnoBinding a bit more readable.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
By using System.nanoTime() instead of currentTimeMillis(), the flakiness
even with the original 10,000 rounds is significantly lower than before.
Making my IDE repeat the test until failure, it took on average 150 runs
to make it fail. So, the more accurate timing helps. With 100,000
rounds, it was even more stable, but eventually I could make it fail.
With 1,000,000 rounds however, even running the test 500x could not make
it fail. So for all practical purposes, I think the test is reasonably
stable now.
Closes #83.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
By increasing from 10,000 to 1,000,000 rounds, the times compared for
performance become considerably longer (but still in the tens or
hundreds or milliseconds), decreasing the probability of the test
failing due to CPU load or some other random effect.
Closes #83.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
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>
This involves replacing references in weaver application code as well as
a few tests.
In order to make AspectJ weaver + tools contain a relocated ASM version,
I added a Maven Shade relocation step after Maven Assembly created the
uber JARs. Relocation works for both binaries and sources and also
encompasses Class::forName calls like in class AsmDetector.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Upon special request by Andy Clement, I included 'lib' as a child module
in the parent POM again, making several modules which refer to
downloaded library files dependent the 'lib' module. I am not sure I
caught all of them, but I hope so.
Now after cloning the project and configuring the token for reading from
GitHub Packages (sorry!), you can just run a Maven build for the main
project and no longer need to fail the first build, read the Maven
Enforcer message and run 'cd lib && mvn compile' as a first step. This
convenience comes at the price of a more complex POM and two new
profiles:
- Profile 'provision-libs' is auto-activated by the absence of a
marker file, kicking off the library provisioning process and
creating same marker file at the end, if successful. Therefore,
during subsequent builds libraries will not be re-provisioned,
because the marker file exists and Maven skips all download and
(un)zip steps, which saves build time and bandwidth. Otherwise
offline builds would not work either.
- Profile 'clean-libs' needs to be activated manually, because by
default 'mvn clean' will not erase provisioned libraries. In most
cases, even after a clean a developer does not want to re-provision
all libraries if they have not changed (e.g. new JDT Core build).
But if you do wish too erase the libraries and the marker file, just
call 'cd lib && mvn -P clean-libs clean'.
Please note: The Maven Enforcer build step, which additionally checks
for existence of other files, still exists and was moved from the parent
POM to 'libs'. No matter if provisioning was just done or skipped
because the main marker file exists, a quick heuristic check for that
list of files is done during each build, failing the build with a
comprehensive message if an inconsistency was found. The error message
says which files are missing and tells the user:
"There is an inconsistency in module subdirectory 'lib'. Please run
'mvn --projects lib -P clean-libs clean compile'. This should take
care of cleaning and freshly downloading all necessary libraries to
that directory, where some tests expect them to be."
This should cover the topic.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch
Andy Clement
Andrey Turbanov