AssertJ项目放弃多版本构建转向纯模块化架构的技术演进

AssertJ作为Java生态中广泛使用的断言库，近期在3.x版本分支中做出了一个重要架构调整：放弃传统的多版本构建(multi-release)方式，全面转向Java模块系统(JPMS)。这一技术决策反映了Java生态向模块化发展的趋势，也体现了AssertJ团队对项目长期维护性的考量。

背景与动机

在Java 9引入模块系统之前，AssertJ采用多版本JAR构建方式来支持不同Java版本的特性。这种方式虽然灵活，但随着Java生态逐渐成熟，模块化已成为现代Java应用的标准配置。多版本构建带来的维护复杂性（如需要维护多套代码）与模块化带来的清晰边界形成了鲜明对比。

AssertJ团队经过评估认为，维护多版本构建的代价已超过其收益，特别是在当前大多数项目都已迁移到Java 11+的环境下。转向纯模块化架构可以简化构建过程，减少潜在的错误点，同时更好地利用模块系统提供的封装优势。

技术实现方案

此次架构调整包含三个主要技术变更：

1. 模块描述文件迁移：将原本位于src/main/java9目录下的module-info.java文件移至标准的主源代码目录src/main/java中。这一变化标志着模块描述成为项目的标准配置而非可选特性。

2. 测试结构调整：创建新的assertj-core-module-path测试模块，专门用于验证在模块路径下的行为。同时将原有的公共API测试迁移至此，确保模块化环境下的功能完整性。

3. 集成测试增强：特别针对与JUnit 4和TestNG等测试框架的集成场景，在模块路径下执行验证测试，包括：

   • 与OpenTest4J集成的JUnit 4场景
   • 同时使用TestNG和JUnit4的混合场景

技术影响与优势

这一架构调整带来了多方面的技术优势：

• 构建简化：消除了多版本构建的复杂性，构建脚本和流程更加清晰
• 维护性提升：不再需要同步维护多套代码，降低了长期维护成本
• 模块化优势：更好地利用JPMS的强封装性，提高代码组织质量
• 兼容性保证：通过专门的模块路径测试确保与现有生态的兼容性

值得注意的是，这一变更主要影响3.x版本分支，而在主分支(main)上，团队已经通过其他提交(如7d873f0d)进一步优化了模块化支持。

总结

AssertJ向纯模块化架构的转变反映了Java生态的成熟趋势。对于使用者而言，这一变化在大多数现代Java环境中应该是透明的，反而会带来更稳定的模块化支持。对于仍在使用传统类路径的极少数场景，可能需要评估升级计划以适应这一架构演进。

这一技术决策展示了AssertJ团队对项目长期健康发展的考量，也体现了其对Java模块化未来的信心。随着Java生态持续演进，类似的架构简化将成为更多库和框架的共同选择。