当 IBM 发布时 Maximo 应用程序套件 (MAS) 9.1 在 2025 年 6 月，大部分头条新闻都发布在 人工智能驱动的助手、移动应用程序增强和扩展的集成功能。但在幕后，对于 IT 和运营团队来说，有一个突出的变化：从 Java 11 向 Java 17 的转变。
‍

乍一看，这可能看起来像是例行的运行时升级。实际上，它会更改安全参数，修改性能行为，并引入兼容性注意事项，这可能会影响从自定义脚本到企业集成的所有方面。如果您将其视为静默更新，则可能会在生产中出现不愉快的意外。

为什么 Java 17 很重要

Java 17是一个长期支持（LTS）版本，这意味着至少可以在2029年之前保持稳定。对于希望减少强制升级和提高生命周期可预测性的管理员来说，这是个好消息。它还符合 IBM 的 MAS 路线图，确保您的环境完全支持未来的增强功能，尤其是人工智能和云原生部署方面的增强。
‍

除了生命周期的好处外，Java 17 还提供：

• 增强的安全性 使用更强的默认 TLS 设置并删除了过时的加密算法。

• 性能改进 通过更快的启动、更高效的内存处理以及 G1 垃圾回收器作为默认设置。

• 现代开发兼容性 因此，新的 MAS 模块和扩展可以在不依赖过时的 API 的情况下运行。
  ‍

这些不是 “好东西” ——它们是保持 MAS 实例安全、高性能并为下一步做好准备的核心。

什么可能会崩溃

并非所有变化都是上行的。 Java 17 强制执行更严格的规则，并删除某些环境仍然依赖的旧功能。例如，如果您有调用已弃用的 API 的自定义 MBO 类或自动化脚本，则这些方法现在可能已完全消失。同样，在 Java 17 更严格的安全默认设置下，围绕旧 JDBC 驱动程序或 SOAP 客户端构建的第三方集成可能会失败。
‍

你可能还会遇到：

• 不支持的 JVM 标志 （例如，useConcmarksweepGC）根本无法被识别。

• 基于反射的 UI 扩展 尝试访问内部 Java 类的程序，现在默认情况下已被阻止。
  ‍
  

最终，如果你在升级之前没有识别出这些依赖关系，它们可能会在生产中以错误的形式出现，有时只是在负载下。

为升级做准备

像对待任何战略变革一样对待这一过渡，将规划、测试和分阶段部署相结合。首先，审核您的 MAS 环境，记录每项自定义、集成和依赖关系。一旦你知道发生了什么，就可以使用 Java 17 搭建一个 MAS 9.1 沙盒实例，并像上线一样运行它——在实际工作负载下测试工作订单、报告、移动同步和集成。
‍

在此过程中：

• 更新 与 Java 17 兼容版本的 JDBC 驱动程序、库和连接器。

• 替换 已弃用 JVM 标志，支持等效标志。

• 回顾 您用于确认加密设置的 java.security 策略会继续生效。
  ‍
  

最后，在影响较小的时候规划生产切换，同时制定回滚路径和明确的利益相关者沟通计划。

升级后验证

一旦你切换了，保持警惕就很重要。监控系统日志中是否存在类未找到错误、方法不匹配或 SSL 握手失败。将 CPU、内存和交易指标与升级前的基准进行比较，以检测细微的性能回归。最重要的是，保持运营团队的反馈渠道畅通——他们通常会第一个发现功能异常。
‍

良好的升级后审查期还应记录所有 “经验教训”，以便下一次主要运行时或 MAS 版本更改更加顺利。

关键要点

MAS 9.1 中的 Java 17 迁移是基础级别的更改，而不仅仅是后台更新。通过将全面的清单、有针对性的测试和仔细的部署相结合，您可以避免中断，同时获得 IBM 在此版本中设计的安全和性能优势。