WorldEdit在Paper服务端下无法加载js.jar的技术分析与解决方案

问题背景

近期有用户反馈，在最新版Paper服务端(1.21.4+)上运行WorldEdit 7.3.10-beta-01时，无法正常加载Rhino脚本引擎(js.jar)。按照官方文档将js.jar放置在plugins或plugins/WorldEdit目录下均无效，系统始终提示找不到脚本引擎。

技术分析

经过深入调查，发现这是Paper服务端的类加载机制导致的兼容性问题。Paper在1.21.4版本后引入了一个新的类加载策略：

1. 类加载路径重定向：Paper会将插件jar包重映射到.plugin-remapped目录下，导致WorldEdit原本设计的类加载路径失效
2. 类路径查找机制：WorldEdit依赖Java的MANIFEST.MF文件中Class-Path条目来定位js.jar，但Paper的重映射破坏了这一机制
3. 文件系统访问：通过strace追踪发现，系统实际查找的是.plugin-remapped目录而非原始plugins目录

解决方案

目前有以下几种可行的解决方案：

临时解决方案

将js.jar直接放入.plugin-remapped/WorldEdit目录下。虽然可行，但不推荐作为长期方案。

推荐解决方案

1. 修改MANIFEST.MF文件：

   • 解压WorldEdit.jar
   • 编辑META-INF/MANIFEST.MF文件
   • 将Class-Path中的"WorldEdit/js.jar"改为"../WorldEdit/js.jar"
   • 重新打包jar文件

2. 等待官方更新： WorldEdit开发团队已注意到此问题，未来版本可能会：

   • 增加多个Class-Path条目以兼容不同加载路径
   • 考虑使用Paper的插件加载API实现可选依赖
   • 评估直接捆绑Rhino引擎的可能性

技术背景

WorldEdit之所以采用外部加载js.jar的设计，有其历史原因：

• 早期Bukkit生态缺乏完善的库依赖管理
• 避免为不使用脚本功能的用户增加不必要的体积
• 当时构建工具对shading(阴影化)的支持有限

最佳实践建议

对于服务器管理员：

1. 优先考虑修改MANIFEST.MF的方案
2. 关注WorldEdit和Paper的更新日志
3. 对于生产环境，建议等待官方修复版本

对于开发者：

1. 了解现代服务端(如Paper)的类加载机制变化
2. 在设计插件依赖时考虑多种加载场景
3. 测试时应在多种服务端实现上进行验证

总结

这个问题反映了Bukkit生态演进过程中插件兼容性面临的挑战。随着Paper等优化服务端的出现，传统插件的设计可能需要相应调整。WorldEdit团队正在积极评估长期解决方案，同时用户可采用文中提供的临时方案确保功能正常使用。