How do you migrate from Java 8 to Java 17?

• Incremental hops: migrate 8 to 11 first (fix removed modules), then 11 to 17 (fix strong encapsulation). Test thoroughly at each hop.
• Removed modules: add Jakarta dependencies for JAXB, JAX-WS, Common Annotations (same as Java 11 migration).
• Strong encapsulation: Java 17 removes --illegal-access entirely. Reflective access to JDK internals fails with InaccessibleObjectException. Fix with --add-opens flags or library upgrades.
• Library updates: bytecode-manipulating libraries (Hibernate, Lombok, Mockito) need Java 17-compatible versions.
• New features: records, sealed classes, pattern matching for instanceof, switch expressions, text blocks all reduce boilerplate.
• Use jdeps --jdk-internals to detect problematic API usage before migration.

What is the recommended migration approach?

Migrate in hops: Java 8 to 11, then 11 to 17. Each LTS boundary introduces specific breaking changes that are easier to fix incrementally.

Java 8  ──→  Java 11 (LTS)  ──→  Java 17 (LTS)
  │              │                    │
  │              ├── Fix removed      ├── Fix strong
  │              │   Java EE modules  │   encapsulation
  │              │                    │
  │              ├── Update           ├── Update
  │              │   libraries        │   frameworks
  │              │                    │
  └──────────────┴────────────────────┴── Run tests

What breaks at each hop?

| Change | Java 8 to 11 | Java 11 to 17 |
|--------|-------------|---------------|
| Removed modules | JAXB, JAX-WS, CORBA | Same (already fixed) |
| Strong encapsulation | Warning only | Error (--illegal-access removed) |
| Default GC | Parallel to G1 | G1 (unchanged) |
| Removed JVM flags | Some CMS flags | CMS removed entirely |
| Framework versions | Spring 4/5, Hibernate 5 | Spring 6, Hibernate 6 |

How do you detect issues before migration?

# Detect use of removed/internal APIs
jdeps --jdk-internals banking-service.jar

# Sample output:
banking-service.jar -> java.base
   com.bank.util.XmlHelper -> sun.misc.BASE64Encoder
   JDK internal API (java.base)

How do you fix strong encapsulation errors?

# Add --add-opens flags for specific modules
java --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -jar banking-service.jar

Better: upgrade the library that uses internal APIs to a version that does not.

What new features can you adopt?

// Records (Java 16+): replace verbose DTOs
record Account(String id, String holder, BigDecimal balance) {}

// Text blocks (Java 15+): multi-line strings
String sql = """
    SELECT id, holder, balance
    FROM accounts
    WHERE branch = 'MUMBAI'
    """;

// Pattern matching instanceof (Java 16+)
if (obj instanceof Account acc) {
    System.out.println(acc.holder());
}

// Switch expressions (Java 14+)
String type = switch (txn.code()) {
    case "N" -> "NEFT";
    case "U" -> "UPI";
    case "R" -> "RTGS";
    default -> "UNKNOWN";
};

What are common mistakes?

WRONG: Jumping directly from Java 8 to 17 without intermediate testing.

WRONG: Adding --add-opens flags without investigating if the library has a newer version that does not need them.

WRONG: Not updating test frameworks (JUnit 4 to JUnit 5, Mockito to latest) alongside the JDK.

What should a senior engineer know?

• The riskiest breakages are not language changes but transitive library dependencies doing deep reflection. Audit them with jdeps first.
• Spring Boot 2.x runs on Java 17, but Spring Boot 3.x requires Java 17+ and uses jakarta.* namespace.
• Docker base images need updating: eclipse-temurin:17-jre instead of openjdk:8-jre.
• Consider running the full test suite at each hop. Treat library upgrades, not language changes, as the main source of risk.