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

引言

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

JPMS模块化的重要性

Java平台模块系统(JPMS)自Java 9引入以来，为Java应用程序带来了更好的封装性、可靠性和性能。模块化能够明确声明模块间的依赖关系，避免隐式依赖带来的问题，同时为构建更精简的运行时环境提供了可能。

对于像Apache Fury这样的基础库来说，支持JPMS不仅能够消除构建时的警告信息，更重要的是为使用Fury的模块化应用程序提供更好的兼容性和可维护性。

Fury的模块化方案选择

在技术实现上，Fury项目面临两个主要选择：

1. 自动模块方案：通过在MANIFEST.MF中添加Automatic-Module-Name条目，这是最轻量级的解决方案，不会影响现有构建流程，且完全向后兼容。

2. 完整模块化方案：提供完整的module-info.java描述符，这需要更复杂的构建配置，但能提供完全的模块化支持。

考虑到Fury目前仍需要支持Java 8用户，且部分依赖库(如Guava)尚未完全支持JPMS，项目团队决定首先采用自动模块方案作为过渡。

模块命名规范

在确定模块名称时，Fury采用了简洁直观的命名方式：

• 核心模块：org.apache.fury.core
• 格式模块：org.apache.fury.format

这种命名方式既保持了与Maven坐标的对应关系，又符合Java模块命名的惯例，便于开发者理解和记忆。

完整模块化的技术挑战

虽然自动模块方案解决了当前的兼容性问题，但未来要实现完整模块化支持仍面临几个技术挑战：

1. 多版本构建：需要支持同时构建Java 8和Java 9+版本，可以采用以下两种方式：

   • 双编译阶段：先编译module-info.java到Java 9，再编译其余代码到Java 8
   • 多版本JAR：将module-info.java放在META-INF/versions/9目录下

2. 依赖兼容性：部分关键依赖(如Guava)尚未提供完整的模块支持，这限制了Fury完全模块化的进程。

3. 测试策略调整：完整模块化后，某些测试可能需要移到集成测试阶段执行，以确保模块声明(如uses和provides)的正确性。

实践经验分享

从技术实现角度看，双编译阶段方案具有以下优势：

• IDE支持良好，开发体验流畅
• module-info.java可以与业务代码放在一起
• 构建配置相对简单

而多版本JAR方案虽然更符合标准，但会带来IDE支持不足和测试流程复杂化的问题。

未来展望

随着Java生态系统的演进，完整模块化支持将成为Apache Fury项目的必然选择。项目团队需要密切关注关键依赖的模块化进展，并适时推进完整模块化工作。同时，保持对Java 8的支持仍将是项目的重要考量因素。

对于其他面临类似问题的Java项目，Fury的经验表明：从自动模块开始，逐步向完整模块化过渡是一个务实可行的技术路线。