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>
- 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>
In ITD processing, use setter instead of assigning Scope directly
Change calls like
pre.scope.parent = newParent;
to this pattern:
// Use setter in order to also update member 'compilationUnitScope'
pre.scope.setParent(newParent);
This should fix lots of failing tests after updating JDT Core.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
After my PR https://github.com/maven-download-plugin/maven-download-plugin/pull/191
was merged and https://github.com/maven-download-plugin/maven-download-plugin/issues/186
was closed, use a new release containing the option misnomer fix in
order to make the POM more readable.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove logging dots per test step in AjcTest.runTest
Methods AjcTest.runTest was logging something like "TEST: ...."
(4 dots), i.e. one dot per performed test step. Not only did this not
add much value, but due to usage of PrintStream.print for line
continuation it also messed up test step logging by scattering seemingly
random dot characters across test step logs. This looked quite ugly, so
I simply removed it.
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>
projects / aspectj.git / log