AspectJ 1.9.27

© Copyright 2026 Contributors. All rights reserved.

Release info: 1.9.27 available Nov-2026

Please note that Bugzilla for issue management is deprecated and new issues should be filed as GitHub issues. The list of issues addressed for 1.9.27 can be found here:

New features

AspectJ 1.9.27 supports Java 27, the final and preview features:

  • 523: Make G1 the Default Garbage Collector in All Environments

  • 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

  • 531: Lazy Constants (Third Preview)

  • 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)

  • 533: Structured Concurrency (Seventh Preview)

  • 534: Compact Object Headers by Default

  • 536: JFR In-Process Data Redaction

  • 537: Vector API (Twelfth Incubator)

  • 538: PEM Encodings of Cryptographic Objects (Third Preview)

Some of these are API/JVM only so don’t affect the compiler and should just work on Java 27 runtimes.

Improvements

Reproducible builds

The class files produced by ajc are now more independent of the order in which the source files are processed, which helps builds of the same sources to produce identical class files on different machines and in different build runs:

  • Aspect class files record just the name of their source file, so they are the same wherever the sources are checked out (#373).

  • Bridge methods in concrete aspects are generated consistently, whatever the order of the source files (#357).

  • Bridge methods, and the permitted subclasses of enums with constant bodies, are written in a fixed order (#383, in the Eclipse compiler that AspectJ builds on).

To be clear, the class files produced before were valid (in Java spec terms), but depending on factors like the order the build tool passed the source files sometimes the output class files varied slightly.

If two builds of the same sources still differ, please raise an issue and attach the differing class files.

Hardening

Following the class file verification added in 1.9.26, AspectJ continues to tighten how it handles external input and files on disk:

  • aop.xml files are parsed with external entity resolution disabled.

  • The shared weaving cache (aj.weaving.cache.impl=shared) is more careful about the directory it uses and what it reads back. If a cache directory is not accepted, the message explains what to change.

Load-time weaving and runtime matching

  • Fewer sun.misc.Unsafe warnings on JDK 24+ when load-time weaving defines the classes it generates (for example for around advice), including when the weaver runs inside Spring’s instrumentation agent.

  • Matching annotations on types by reflection, as used by Spring AOP, is cheaper at startup because runtime-retention annotations are read by reflection instead of parsing the class files again, and matching on annotation values of types is more robust (#371, #372).

Other changes and bug fixes

  • Anonymous classes that declare fields but no methods (including enum constants with a body and fields) are compiled correctly again (#353).

  • The BCEL classes understand the PermittedSubclasses attribute, and lazily unpacked class file attributes are safe to use from several threads (#364).

  • The version time is parsed with a fixed locale (#362).

  • The handling of @Deprecated reported in #316 and #322 works correctly with the updated Eclipse compiler, and regression tests were added.

Worth repeating - AspectJ 1.9.26 included a number of changes to do more in depth verification of class files. This verification is intended to ensure bad data will cause AspectJ to fail with a proper exception rather than a stack overflow or an out of memory issue. Please raise an issue if you see anything that looks like the verification is being too strict, however the extra checks are not expected to cause any issues for class files resulting from typical usage of Java and AspectJ.

Importantly with the adoption of JDT Compiler later than 22, the versions of Java 1.1 > 1.7 are considered no longer supported so any attempt to specify a build for any of those Java versions will now fail immediately.

AspectJ usage hints

AspectJ compiler build system requirements

Since 1.9.21, the AspectJ compiler ajc (contained in the aspectjtools library) no longer works on JDKs 11 to 16. The minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime aspectjrt and the load-time weaver aspectjweaver still only require JRE 8+.

History: Since 1.9.8, the AspectJ compiler ajc needed JDK 11+, before then JDK 8+.

Use LTW on Java 16+

Since AspectJ 1.9.21.1, using --add-opens is no longer necessary! The additional JVM command-line option was necessary for LTW on JRE 16+ in all AspectJ versions up to 1.9.21. Since AspectJ 1.9.21.1, the LTW agent uses an alternative approach for defining new classes during weaving, which works without --add-opens - at least for now, i.e. JDKs 8 to 22. There still is no canonical solution, because JDK-8200559 is still unresolved since 2018.

Compile with Java preview features

For features marked as preview on a given JDK, you need to compile with ajc --enable-preview and run with java --enable-preview on that JDK.

Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation. For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still need to recompile, no matter what.

Thanks

Thank you to everyone who contributed to this release, by reporting issues, providing reproducers and sending changes:

  • nabhan06 for improvements to the weaving cache, aop.xml parsing and class file attribute handling (#359, #360, #361, #364)

  • tommyk-gears for the improvements to annotation matching by reflection (#371, #372)

  • alamar (#357), saicharanvennapusa (#353), lprimak (#362), lefou (#316) and zuckel (#322) for reporting issues that were fixed in this release