When IBM released Maximo Application Suite (MAS) 9.1 in June 2025, most of the headlines went to AI-powered assistants, mobile app enhancements, and expanded integration capabilities. But under the hood, one change stands out for IT and operations teams: the shift from Java 11 to Java 17.
‍

At first glance, this might seem like a routine runtime upgrade. In reality, it changes security parameters, modifies performance behavior, and introduces compatibility considerations that could impact everything from custom scripts to enterprise integrations. If you treat it as a silent update, you risk unpleasant surprises in production.

Why Java 17 Matters

Java 17 is a Long-Term Support (LTS) release, which means stability until at least 2029. That’s good news for admins who want fewer forced upgrades and a more predictable lifecycle. It also aligns with IBM’s MAS roadmap, ensuring that future enhancements—especially those in AI and cloud-native deployment—are fully supported in your environment.
‍

Beyond lifecycle benefits, Java 17 offers:

• Enhanced security with stronger default TLS settings and the removal of obsolete cryptographic algorithms.

• Performance improvements through faster startup, more efficient memory handling, and the G1 garbage collector as the default.

• Modern development compatibility so new MAS modules and extensions can run without relying on outdated APIs.
  ‍

These are not “nice-to-haves”—they’re core to keeping your MAS instance secure, performant, and ready for what’s next.

What Could Break

Not all changes are upside. Java 17 enforces stricter rules and drops legacy features that some environments still rely on. For example, if you have custom MBO classes or automation scripts that call deprecated APIs, those methods may now be gone entirely. Likewise, third-party integrations built around old JDBC drivers or SOAP clients can fail under Java 17’s tightened security defaults.
‍

You may also encounter:

• Unsupported JVM flags (e.g., UseConcMarkSweepGC) that simply won’t be recognized.

• Reflection-based UI extensions that attempt to access internal Java classes, now blocked by default.
  ‍
  

Ultimately, if you don’t identify these dependencies before upgrading, they could surface as errors in production—sometimes only under load.

Preparing for the Upgrade

Approach this transition as you would any strategic change, blending planning, testing, and staged rollout. Start by auditing your MAS environment, documenting every customization, integration, and dependency. Once you know what’s in play, stand up a sandbox MAS 9.1 instance with Java 17 and run it like it’s live—test work orders, reporting, mobile sync, and integrations under real workloads.
‍

Within this process:

• Update JDBC drivers, libraries, and connectors to Java 17–compatible versions.

• Replace deprecated JVM flags with supported equivalents.

• Review your java.security policies to confirm encryption settings carry over.
  ‍
  

And finally, plan your production cutover during low-impact hours, with both a rollback path and a clear stakeholder communication plan in place.

Post-Upgrade Verification

Once you’ve switched over, vigilance matters. Monitor your system logs for class-not-found errors, method mismatches, or SSL handshake failures. Compare CPU, memory, and transaction metrics to your pre-upgrade baselines to detect subtle performance regressions. Most importantly, keep feedback channels open with operations teams—often they’ll be the first to spot functional anomalies.
‍

A good post-upgrade review period should also capture any “lessons learned” so that the next major runtime or MAS version change is smoother.

Key Takeaways

The Java 17 migration in MAS 9.1 is a foundation-level change, not just a background update. By blending thorough inventory, targeted testing, and careful rollout, you can avoid disruptions while gaining the security and performance benefits that IBM designed into this release.