Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around ArchUnit’s compatibility with future JDK versions.
This is not a request for the official project to immediately raise its minimum Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, ArchUnit, as a Java architecture testing and bytecode analysis library, needs to read, import, and analyze class files produced by different JDK versions. The project itself still keeps a relatively low minimum Java baseline, while actively tracking newer Java class file versions, including support for Java 21, Java 24, Java 25, and even Java 26 class files.
This strategy is especially important for ArchUnit. Its compatibility is not only about which JDK ArchUnit itself runs on, but also about whether it can correctly analyze class files produced by user projects compiled with different Java versions. As a result, newer JDKs may affect not only builds and tests, but also class file major versions, ASM / bytecode parsing, new language features, module-info, multi-release jars, preview features, sealed classes, records, and other bytecode-level details.
Because of that, our goal is not to push ArchUnit to raise its minimum Java baseline right now. It is also not to ask the project to change its current compatibility strategy. Instead, we would like to do external compatibility validation while the current strategy remains unchanged.
More specifically, we would like to observe ArchUnit’s build, test, runtime, and class file analysis behavior on JDK 21, JDK 25, JDK 26, and later JDK versions. For ArchUnit, this kind of validation is not limited to whether the project builds successfully on a newer JDK. It also includes whether ArchUnit can correctly import and analyze class files generated by newer JDKs, and whether existing architecture rules continue to behave consistently with new bytecode structures, new language features, or new class file attributes.
Even though ArchUnit already actively tracks Java 25 / Java 26 class file support, JDK evolution will not stop at JDK 25. Future JDK releases may continue to introduce new class file major versions, new language features, new bytecode attributes, preview features, or changes related to the module system, javac, and build toolchains.
Because of that, we believe this kind of external compatibility validation would still be useful. The goal is not to duplicate the project’s existing work, but to observe the impact of future JDK versions early while keeping the current compatibility strategy unchanged. If the project later needs to support a new Java version or a new class file version, the external validation results could serve as useful reference material, help narrow down issues faster, reduce investigation cost, and save maintenance time.
This kind of validation may include, but is not limited to:
- ArchUnit’s build and test behavior on JDK 21, JDK 25, JDK 26, or later versions
- How
ClassFileImporter imports and parses newer Java class file major versions
- Compatibility of ASM / bytecode parsing dependencies with future JDK class files
- Behavioral differences involving
module-info, multi-release jars, sealed classes, records, switch patterns, preview features, and similar constructs
- The impact of new class file attributes or new Java language features on architecture rule evaluation
- JUnit 4 / JUnit 5 integration behavior on newer JDKs
- Issues users may encounter when running ArchUnit tests in Gradle or Maven projects on newer JDKs
- Compatibility issues related to the Java module system,
--add-exports, javac internal APIs, or build toolchain changes
- CI, test matrix, or local development environment issues on future JDK versions
- Issues users may encounter when using ArchUnit on newer Java runtime environments
Our current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, with the current minimum Java baseline, current class file support strategy, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future adaptation to new JDKs, new class file versions, or new Java language features.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks ArchUnit may face with future JDK versions, new class file versions, new Java language features, or bytecode changes as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, class file support, dependency upgrades, or CI/test matrix expansion.
Thank you for your time, and thank you for maintaining ArchUnit！
Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around ArchUnit’s compatibility with future JDK versions.
This is not a request for the official project to immediately raise its minimum Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, ArchUnit, as a Java architecture testing and bytecode analysis library, needs to read, import, and analyze class files produced by different JDK versions. The project itself still keeps a relatively low minimum Java baseline, while actively tracking newer Java class file versions, including support for Java 21, Java 24, Java 25, and even Java 26 class files.
This strategy is especially important for ArchUnit. Its compatibility is not only about which JDK ArchUnit itself runs on, but also about whether it can correctly analyze class files produced by user projects compiled with different Java versions. As a result, newer JDKs may affect not only builds and tests, but also class file major versions, ASM / bytecode parsing, new language features,
module-info, multi-release jars, preview features, sealed classes, records, and other bytecode-level details.Because of that, our goal is not to push ArchUnit to raise its minimum Java baseline right now. It is also not to ask the project to change its current compatibility strategy. Instead, we would like to do external compatibility validation while the current strategy remains unchanged.
More specifically, we would like to observe ArchUnit’s build, test, runtime, and class file analysis behavior on JDK 21, JDK 25, JDK 26, and later JDK versions. For ArchUnit, this kind of validation is not limited to whether the project builds successfully on a newer JDK. It also includes whether ArchUnit can correctly import and analyze class files generated by newer JDKs, and whether existing architecture rules continue to behave consistently with new bytecode structures, new language features, or new class file attributes.
Even though ArchUnit already actively tracks Java 25 / Java 26 class file support, JDK evolution will not stop at JDK 25. Future JDK releases may continue to introduce new class file major versions, new language features, new bytecode attributes, preview features, or changes related to the module system, javac, and build toolchains.
Because of that, we believe this kind of external compatibility validation would still be useful. The goal is not to duplicate the project’s existing work, but to observe the impact of future JDK versions early while keeping the current compatibility strategy unchanged. If the project later needs to support a new Java version or a new class file version, the external validation results could serve as useful reference material, help narrow down issues faster, reduce investigation cost, and save maintenance time.
This kind of validation may include, but is not limited to:
ClassFileImporterimports and parses newer Java class file major versionsmodule-info, multi-release jars, sealed classes, records, switch patterns, preview features, and similar constructs--add-exports, javac internal APIs, or build toolchain changesOur current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, with the current minimum Java baseline, current class file support strategy, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future adaptation to new JDKs, new class file versions, or new Java language features.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks ArchUnit may face with future JDK versions, new class file versions, new Java language features, or bytecode changes as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, class file support, dependency upgrades, or CI/test matrix expansion.
Thank you for your time, and thank you for maintaining ArchUnit！