Java 17 Migration Guide for AEM 6.5 LTS Bundles

By Alberto Zarza Martín · · 7 min read

Moving OSGi bundles from Java 8/11 to the Java 17 baseline required by AEM 6.5 LTS is usually more about the strict module system than about language syntax. Here is where teams actually lose time.

Compilation-level issues

Most business logic compiles unchanged. The exceptions are code that relies on removed APIs like sun.misc.Unsafe internals, old JAXB classes no longer bundled by default, or reflection against private JDK fields. Run a straight recompile first — it surfaces the majority of issues before you even touch a running instance.

Reflection and strong encapsulation

Java 17 enforces strong encapsulation of internal JDK packages by default. Libraries that reach into java.base internals via reflection will throw InaccessibleObjectException at runtime, not at compile time. If a third-party library in your dependency tree does this, you will need either an updated version of that library or an explicit --add-opens flag, which is awkward to apply cleanly inside an OSGi container.

Maven toolchain

Update the maven-compiler-plugin source/target (or release) to 17, and verify your CI build agents actually have a Java 17 JDK installed — a surprising number of pipeline failures at this stage are simply the CI image still running Java 11.

<properties>
  <maven.compiler.release>17</maven.compiler.release>
</properties>

OSGi bundle manifest impact

Bundles that generate their manifest via bnd-maven-plugin usually need no manual changes for the Java version itself, but double-check any hardcoded Bundle-RequiredExecutionEnvironment headers left over from older archetypes — a stale JavaSE-1.8 header will not stop the bundle from starting, but it is a signal the project template itself needs updating.

Testing priority

Prioritize regression testing around: serialization/deserialization code, any custom class loading, and third-party libraries with a history of reflection-heavy internals (older versions of Jackson, some PDF and image processing libraries). These are disproportionately likely to surface Java 17 issues that unit tests alone will not catch.