Remove Apache Commons from 'lib' module, update remaining dependencies
Of beanutils, collections, digester and logging actually only digester
and logging are directly used in AspectJ code. Therefore, remove the
unused ones and upgrade the remaining libraries' versions to ones which
also have source JARs on Maven Central. This makes downloading sources
from GitHub and packaging separate commons.jar and commons-src.zip
artifacts superfluous. Hence, we can get rid of them completely.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
New abstract class JavaVersionSpecificXMLBasedAjcTestCase
Replaces now obsolete base classes
- XMLBasedAjcTestCaseForJava[n]OrLater,
- XMLBasedAjcTestCaseForJava[n]Only.
The new class is parametrised with minimum and maximum Java version and
hence can replace all the other classes. This does not only apply the
DRY principle, but also makes adding tests for new Java versions less
tedious.
By chance, I also noticed missing sanity tests for Java 12, which I
added as a little drive-by benefit.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
LangUtil: remove methods like 'is11VMOrGreater', 'is1dot5VMOrGreater'
Replace them by a uniform method 'isVMGreaterOrEqual(double)', also
overloaded for int.
This gets rid of one 'AspectJ_JDK_Update' tag. One less place to check
and update with each newly supported Java version. :-)
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The hint is meant to help AspectJ developers identify the places where
there are to-dos for releases supporting new Java versions. This is work
in progress, new tags can be added wherever necessary in the future. But
for now, the most important places should be covered:
- AJC version string
- Test infrastructure (test suites, classes and XML files)
- BCEL class file version MAJOR_*, MINOR_* constants
- AjcTask constants for compiler source, target, release
- LangUtil::is*VMOrGreater methods
- ASM and JDT Core dependency versions
- CI workflow file
- Release notes
The to-do to check the tagged places is also mentioned in RELEASE.md.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Globally replace "http:" by "https:" in non-XML files
Maybe, the XML files and Maven wrapper files will follow. First, let us
find out if this breaks the build, maybe some tests are asserting on
"http:". But there, the replacement would also have taken place, so
probably it just works.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe
instances and method handles pointing to their 'defineClass' methods.
Those now work universally on JDKs 8-21. In older JDKs, the method used
to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe.
It is challenging to fetch instances, especially as reflection
protection and module boundaries have been increased in the JDK
progressively. But finally, a solution was adapted from Byte Buddy (BB).
Kudos to BB author Rafael Winterhalter. The previous solution to use
ClassLoader::defineClass and require '--add-opens' is no longer
necessary for the first time since it became necessary in AspectJ 1.9.7
with Java 16 support.
Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm
was used before. Maybe that is too many places, but no worse than before.
Add missing dependency on loadtime to aspectjweaver. This kept a build
like "mvn install -am -pl aspectjweaver" from picking up changed
loadtime classes.
Fixes #117.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Move release notes README-*.adoc to separate directory
Also move two more release-related documents.
All referenced images are now in a common subdirectory.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- AspectJ Browser (ajbrowser)
- Forte IDE integration
- JBuilder IDE integration
- Emacs integration
All this information was old and outdated. Ajbrowser was removed from
AspectJ a while ago. If the other tools even still exist, any possibly
existing AspectJ support is not part of AspectJ itself.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Currently, the situation looks more like a Java 21 maintenance release
than directly a Java 22 release.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The tests and their XML definitions are still copy & paste and need to
be cleaned up. Separate Java 21 feature tests do not exist yet.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
AntSpec: Improve filter for warning "Archived non-system classes are disabled"
In JDK 21, the prefix has changed once again, no longer being a JVM
specifier like "OpenJDK 64-Bit Server VM" or "Java HotSpot(TM) 64-Bit
Server VM" but rather something like "[0.016s][warning][cds]".
Even worse, before J21, the warning appears on stdErr, but in J21+, it
appears on stdOut.
Fixes LTWTests.testJ14LTWWithXML, which started failing on Java 21.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
OutputSpec.matchesThisVm better supports version ranges
vmVersionRanges might be a single version like "9", a list of versions
like "1.2,1.3,1.4,1.5", an equivalent range of "1.2-1.5", an open range
like "-1.8", "9-" (equivalent to "9+") or a more complex list of ranges
like "-1.6,9-11,13-14,17-" or "8,11,16+".
Empty ranges like in "", " ", "8,,14", ",5", "6-," will be ignored.
I.e., they will not yield a positive match.
Bogus ranges like "9-11-14" will be ignored, too.
Existing XML test specs using '<line text="..." vm="v,v2,...,vn"/>
have been adjusted to use version ranges rather than long lists of
consecutive versions. Furthermore, ranges with a trailing '+' like '14+'
were replaced by using the new canonical format '14-', even though the
parser still correctly recognises '14+'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
For now, only the "pattern matching for switch" tests from previews 1
and 2 were adjusted to work in preview 3, because guarded patterns were
replaced by 'when' clauses in 'switch' blocks. Therefore, existing test
classes did not compile anymore and had to be replaced by syntactically
upgraded versions with content merged from preview 1 and 2 classes.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This fixes a partial path traversal vulnerability.
Replaces `dir.getCanonicalPath().startsWith(parent.getCanonicalPath())`, which is vulnerable to partial path traversal attacks, with the more secure `dir.getCanonicalFile().toPath().startsWith(parent.getCanonicalFile().toPath())`.
To demonstrate this vulnerability, consider `"/usr/outnot".startsWith("/usr/out")`.
The check is bypassed although `/outnot` is not under the `/out` directory.
It's important to understand that the terminating slash may be removed when using various `String` representations of the `File` object.
For example, on Linux, `println(new File("/var"))` will print `/var`, but `println(new File("/var", "/")` will print `/var/`;
however, `println(new File("/var", "/").getCanonicalPath())` will print `/var`.
Weakness: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Severity: Medium
CVSSS: 6.1
Detection: CodeQL & OpenRewrite (https://public.moderne.io/recipes/org.openrewrite.java.security.PartialPathTraversalVulnerability)
Reported-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>
Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>
Bug-tracker: https://github.com/JLLeitschuh/security-research/issues/13
Co-authored-by: Moderne <team@moderne.io>
Previously 'ordered="no"' was only permitted for 'stderr'. We need this
for tests with asynchronous log output on standard error.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch
Jonathan Leitschuh