Apache Fury项目中的JPMS模块化支持实践

引言

随着Java平台模块系统(JPMS)的普及，越来越多的Java项目开始考虑模块化支持。Apache Fury作为一个高性能的序列化框架，近期也面临了如何优雅支持JPMS的需求。本文将深入探讨Fury项目在模块化支持方面的技术决策和实践经验。

JPMS模块化的必要性

在Java 9引入模块系统后，未声明模块名称的JAR文件会被视为自动模块(automatic modules)，这会导致构建时出现警告信息。对于像Fury这样的库项目来说，明确声明模块名称不仅能消除这些警告，还能为未来的完全模块化做好准备。

模块化方案选择

Fury项目团队经过评估，确定了两个可行的模块化路径：

1. 最小化方案：通过在MANIFEST.MF中添加Automatic-Module-Name条目来声明模块名称。这种方式简单易行，不影响现有构建流程，且完全向后兼容。

2. 完整模块化：提供完整的module-info.java描述符。这需要更复杂的构建配置，可能涉及多版本JAR或双阶段编译，但能提供完全的模块化支持。

实施细节

Fury项目最终选择了最小化方案作为第一步，主要考虑因素包括：

• 部分依赖(如Arrow)尚未发布JPMS支持版本
• 需要保持对Java 8的长期支持
• 简单性优先，逐步演进

模块命名采用了"org.apache.fury.core"、"org.apache.fury.format"等直观的层级命名方式，既保持了与项目结构的一致性，又符合Java模块命名规范。

未来展望

虽然当前采用了最小化方案，但团队已经规划了完整的模块化路线图。未来可能采用的完整模块化方案有两种主要实现方式：

1. 双阶段编译：先以Java 9+编译module-info.java，再用Java 8编译其余代码。这种方式的优点是IDE支持良好，缺点是会混入Java 9+编译的类文件。

2. 多版本JAR：将module-info.java放在单独的源目录中，构建为多版本JAR。这种方式更规范，但会带来测试流程的复杂性。

经验分享

从技术实践来看，模块化过程中需要注意几个关键点：

• 依赖项的模块化状态会直接影响项目的模块化策略
• 测试流程需要相应调整，特别是涉及服务加载(uses/provides)的情况
• 构建工具(Maven/Gradle)的配置需要精心设计以支持多版本编译

结语

Apache Fury的模块化实践展示了一个成熟项目如何逐步拥抱JPMS。从简单的模块名称声明开始，到规划完整的模块化支持，这种渐进式演进策略既保证了当前版本的稳定性，又为未来发展奠定了基础。对于其他类似项目而言，Fury的经验提供了有价值的参考。