关于documents4j升级至Java 17及Java 11支持的技术咨询

问题背景 #

documents4j当前基于Java 11构建，该版本的Oracle标准支持已结束，SAP的支持也将于2024年底终止。用户尝试用Java 17构建documents4j未成功，提出以下问题：

1. documents4j是否有从Java 11升级至Java 17的计划？ #

目前官方暂未公开明确的Java 17升级计划，可留意项目的官方发布渠道或代码仓库的更新公告获取后续信息。

2. 若暂无升级计划，大致需要多少工作量？能否仅升级部分模块（例如documents4j-transformer-msoffice）？ #

• 工作量：整体升级到Java 17的工作量取决于项目依赖兼容性、Java 11专属API的替换量、模块系统适配情况等。如果多数依赖已支持Java 17，主要工作集中在API调整、编译配置更新和全链路测试，大概需要数人周的工作量；若存在大量未兼容的老旧依赖，工作量会明显增加。
• 部分模块升级：仅升级单个模块理论上可行，但要注意该模块与其他核心模块的依赖关联。核心模块仍基于Java 11时，升级后的模块可能出现字节码版本不匹配、依赖API差异等兼容性问题，反而会增加适配复杂度，不建议单独升级单个模块。

3. 是否有成本合理的Java厂商仍支持Java 11？ #

• Red Hat：提供Java 11的长期支持，有付费企业方案也有免费社区版本支持，成本可控。
• Azul Zulu：免费提供OpenJDK 11的长期支持，同时有灵活的付费商业支持选项，适配不同规模团队需求。
• IBM Semeru Runtime：针对Java 11有免费社区支持和付费企业级支持方案，成本合理，适合需要稳定支持的场景。

补充：用Java 17构建documents4j未成功，大概率是项目依赖、编译配置或代码存在Java 17不兼容内容，可先排查项目构建文件（如pom.xml或build.gradle）的编译版本配置，以及依赖库的Java版本兼容性。

内容的提问来源于stack exchange，提问作者user25604553