Make sure that program arguments are passed through in full LTW mode
This fixes e.g. LTWTests.testDeclareAbstractAspect, which passes on
names of ITD methods to the test program, which in turn executes those
methods via reflection.
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>
It was referring to a no longer existent weaver under
aj-build/dist/tools/lib/aspectjweaver.jar, which now has been replaced
by the new file lib/aspectj/lib/aspectjweaver.jar.
Several tests were broken, not finding the agent. But because those
tests make no assertions, nobody ever noticed. Only when I had to change
some LTW tests from in-process to full LTW mode (see next commit) due to
them now obviously calling some code paths which need '--add-opens', I
even noticed the problem.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Bump actions/setup-java from 1 to 3, use Temurin, drop Java 14
Adopt OpenJDK moved to Eclipse Temurin and is no longer updated. Temurin
builds for JDK 14 are however not available. Therefore, we drop the JDK
14 CI build.
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 1 to 3.
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](https://github.com/actions/setup-java/compare/v1...v3)
Otherwise, Dependabot would run builds whenever something is pushed on
master and it rebases its PR. It is still possible to just click on the
skipped workflow in the PR and then issue "re-run all jobs" in order to
perform a build.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
It will create PRs for Maven and GitHub action updates. Of course, we
cannot simply merge the PRs, because Dependabot has not singed an
Eclipse CLA, but at least we know about updates and how they affect the
build result. Then we can decide to clone the changes and commit them
manually.
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>
Andy Clement [Tue, 18 Jan 2022 01:47:37 +0000 (17:47 -0800)]
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.
Optimize class loading - make backward compatible with legacy behaviour
Now the defaults are:
+ org.aspectj.apache.bcel.useSingleRepositoryInstance (default: false)
+ org.aspectj.apache.bcel.useUnavailableClassesCache (default: false)
+ org.aspectj.apache.bcel.ignoreCacheClearRequests (default: false)
I.e. the new caching optimisations are opt-in instead of opt-out as
originally designed. This might change in the future, but for now
without any additional tests and experience with the new feature let us
be conservative and make the build green first.
I also added a few more code review findings concerning backward
compatibility, which was less than 100% even with all three flags
deactivated.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Stefan Starke [Tue, 8 Oct 2019 11:27:41 +0000 (13:27 +0200)]
Optimize class loading
In our project we found out that during the build up of the spring context
the class loading takes a very long time.
Root cause is the huge amount of file I/O during pointcut class loading.
We are taking about ~250k file loads.
With these changes we managed to cut down the starting time by around 50%.
What we found out is that IMHO - the clear method of the ClassLoaderRepository
is called far too often -> in our settings this resulted in not a single cache
hit as the cache got cleared permanently.
Therefore we de-actived the cache clear calls inside the ClassLoaderRepository.
Secondly we changed the Java15AnnotationFinder in a way to not always create
new objects for the ClassLoaderRepository but re-use one static instance.
Otherwise we experienced >100k objects being created.
Last but not least we introduced a cache for unavailable classes so that
they do not have to be looked up using file I/O over and over again.
The whole behavior is configurable via
+ org.aspectj.apache.bcel.useSingleRepositoryInstance (default: true)
+ org.aspectj.apache.bcel.useUnavailableClassesCache (default: true)
+ org.aspectj.apache.bcel.ignoreCacheClearRequests (default: true)
Signed-off-by: Stefan Starke <stefan@starkeweb.org> Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Andy Clement [Fri, 7 Jan 2022 06:18:21 +0000 (22:18 -0800)]
Fix ConstantDynamic to use the right tag.
The class ConstantDynamic was incorrectly using the `InvokeDynamic` tag
during construction which meant after reading in code containing a
`Dynamic` reference, it would incorrectly be written out as an
`InvokeDynamic` reference. There is not much code out there using
Dynamic so wasn't uncovered before.
Andrey Turbanov [Sat, 20 Nov 2021 17:37:02 +0000 (20:37 +0300)]
Cleanup redundant boxing.
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.
Andrey Turbanov [Sat, 20 Nov 2021 14:31:33 +0000 (17:31 +0300)]
Trim trailing whitespaces.
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.
Andrey Turbanov [Sat, 20 Nov 2021 13:53:30 +0000 (16:53 +0300)]
According to javadoc File.isDirectory 'true' if and only if the file denoted by this abstract pathname exists and is a directory.
It means that separate File.exists() check before File.isDirectory() check is redundant.
Background: When only consuming dependencies or plugins from OSSRH
snapshots, there is no need to differentiate between the classic and
new URLs. This is only relevant when deploying snapshots, i.e. in the
'distributionManagement' POM section.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove Java 8 from GitHub workflow (ECJ needs Java 11+)
Since JDT Core 3.27 (Java 17) and Eclipse 2021-09 (4.21), respectively,
ECJ no longer works on JDK 8. Even if we backport JDT Core classes, some
of its dependencies contain Java 11 class files, which ultimately also
means that ACJ no longer works below JDK 11 due to those transitive
dependencies, e.g. org.eclipse.core.resources-3.14.0.jar.
For now, I added JDK 14 to the build matrix, i.e. we currently have 11,
14, 17. When JDK 18 is released, we can switch to 11, 17, 18, i.e. keep
the two LTS releases plus the latest one.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Rename DOM AST class TypePattern to AbstractTypePattern
Since JDT Core 3.27 (Java 17), there is a name clash, because the new
class org.eclipse.jdt.core.dom.TypePattern (JEP 406) gets relocated to
org.aspectj.org.eclipse.jdt.core.dom.TypePattern during shading.
Fortunately, this made tests like AjASTTest and AjAST5Test fail with
rather nasty errors like:
java.lang.VerifyError: Bad return type (...)
Type 'org/aspectj/org/eclipse/jdt/core/dom/TypePattern' (...) is not
assignable to 'org/aspectj/org/eclipse/jdt/core/dom/Pattern' (...)
TODO: Update AJDT references to the renamed class in the following
classes after refreshing the AspectJ sources:
- ExtraPackageReferenceFinder
- ExtraTypeReferenceFinder
This also means, that for Eclipse 2021-09 (4.21) we need a new AJDT
update site, because simply deploying to the 4.19 one would probably
lead to problems in the IDE.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add JDK 16+ workaround for Nexus Staging Maven Plugin
Plugin version 1.6.8 does not work on JDK 16+ without special MAVEN_OPTS
opening certain modules, because the XStream version used needs it. One
workaround is to use a more recent XStream version.
TODO: remove plugin dependency after OSSRH-66257, NEXUS-26993 are fixed. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
projects / aspectj.git / log