Rhino项目模块结构调整方案解析

背景介绍

Mozilla Rhino作为Java平台上的JavaScript引擎实现，近期对其模块结构进行了重大调整。这一调整主要针对Java 9引入的模块系统(JPMS)进行优化，旨在提供更好的模块化支持。然而，新结构在向后兼容性方面存在一些问题，特别是对于已经采用模块化Java并使用Rhino 1.7.14及以后版本的项目。

现有模块结构分析

当前master分支的模块结构如下：

• rhino-runtime模块：org.mozilla.rhino-runtime，对应rhino-runtime.jar，包含核心类
• rhino-tools模块：org.mozilla.rhino-tools，对应rhino-tools.jar，包含Shell和调试器
• rhino-xml模块：org.mozilla.rhino-xml，对应rhino-xml.jar，包含XML实现
• rhino-engine模块：org.mozilla.rhino-engine，对应rhino-engine.jar，包含脚本引擎
• 非模块化rhino.jar：包含所有功能的单一JAR包

这种结构带来的主要影响包括：

1. 依赖"rhino"模块的模块化应用需要改为导入"rhino-runtime"
2. 使用"rhino.jar"的模块化应用需要改用其他JAR
3. 非模块化应用虽然可以继续使用旧JAR，但建议迁移到新模块化JAR

提出的改进方案

方案一：重命名核心模块

1. 将"rhino-runtime"模块重命名为"rhino"
2. 将全功能JAR重命名为"rhino-all"

调整后的结构：

• 核心模块：org.mozilla.rhino，对应rhino.jar
• 全功能JAR：rhino-all.jar

优势：

• 最大程度符合Java模块化精神
• 模块化项目构建配置改动最小
• 清晰的命名区分核心模块和全功能包

影响：

• 依赖工具或XML功能的项目需要调整依赖
• 命令行工具需要更新使用的JAR名称

方案二：仅调整模块名

1. 仅修改"rhino-runtime"的模块名为org.mozilla.rhino
2. 保持其他结构不变

优势：

• 非模块化应用完全不受影响
• 改动范围最小

缺点：

• 模块名与JAR名不一致
• 长期来看不利于推广模块化使用

方案三：全功能JAR支持自动模块

1. 使全功能JAR成为自动模块
2. 导出所有包含的模块和包

问题：

• 违反模块化原则，同一包可能被多个模块导出
• 可能导致难以诊断的依赖冲突
• 不利于长期维护

技术社区反馈

技术社区成员普遍倾向于方案一，主要考虑因素包括：

1. 模块化一致性：方案一最符合Java模块化设计原则
2. 长期可维护性：清晰的模块边界有利于未来扩展
3. 构建工具兼容性：Maven/Gradle等自动化构建工具用户迁移成本低
4. 命名合理性：避免模块名与JAR名不一致的问题

特别是对于自动模块方案(方案三)，专家指出其违反了模块化的基本规则，可能导致运行时出现难以预测的问题，因此强烈不建议采用。

实施建议

基于技术分析和社区反馈，建议采用方案一进行模块结构调整。实施时应注意：

1. 版本兼容性：明确标注版本变更带来的破坏性变化
2. 迁移指南：提供详细的从旧版本迁移的文档
3. 过渡期支持：考虑在一定时期内提供兼容层
4. 构建工具支持：确保主流构建工具能够正确处理新模块结构

这种调整虽然短期内可能带来一些迁移成本，但从长远来看，更清晰的模块结构和命名规范将显著提升项目的可维护性和用户体验。