Finalized in Java 17 (JEP 415). Extends JEP 290 (Java 9), which introduced the basic deserialization filter API. Why Deserialization Is Dangerous Java object deserialization (ObjectInputStream.readObject()) is one of the most exploited attack surfaces in Java. When a Java application deserializes untrusted bytes, the JVM instantiates arbitrary classes and calls their methods as a side effect — before your application code even sees the result. Attackers craft gadget chains: sequences of serializable classes in common libraries (Apache Commons Collections, Spring Framework, etc.

Finalized in Java 17 (JEP 356). The Problem with Java’s Old PRNG API Java’s random number generation before Java 17 had several problems: 1. java.util.Random has poor statistical properties. The default PRNG algorithm is a 48-bit linear congruential generator (LCG). It fails many statistical tests (spectral test, birthday test). Its 2^48 period is short — exhaustible in seconds on modern hardware. 2. No common interface. java.util.Random, java.util.concurrent.ThreadLocalRandom, java.util.SplittableRandom, and java.

Incubator Feature in Java 17 (JEP 412 — First Incubator). Package: jdk.incubator.foreign. Requires --add-modules jdk.incubator.foreign at compile and runtime. This API evolved significantly across Java 18 (JEP 419), 19 (JEP 424), 20 (JEP 434), and was finalized in Java 22 (JEP 454). See the Java 21 article series for the final API. This article covers the Java 17 incubator version and the Project Panama vision. Why Replace JNI? Java Native Interface (JNI) has been the way to call native code from Java since Java 1.

Production Baseline JVM Flags Start every Java 17 production deployment with this baseline: java \ # GC — choose one (see GC section) -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ \ # Heap sizing -Xms4g -Xmx4g \ \ # GC logging — essential for diagnosis -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=20m \ \ # OOM diagnostics -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=/var/log/app/heap-dump.hprof \ -XX:+ExitOnOutOfMemoryError \ \ # Metaspace -XX:MaxMetaspaceSize=512m \ \ # Code cache -XX:ReservedCodeCacheSize=512m \ \ # JFR — always-on profiling -XX:StartFlightRecording=duration=0,filename=/var/log/app/profile.

Java 17: The Landmark LTS Java 17 was released on September 14, 2021 as a Long-Term Support (LTS) release. It is the successor to Java 11 (released September 2018) as the recommended production baseline for enterprise and cloud Java deployments. Between Java 11 and Java 17, six non-LTS releases (Java 12 through 16) delivered a continuous stream of language improvements on a six-month cadence. Java 17 is where five of the most important new features — Records, Sealed Classes, Pattern Matching for instanceof, Text Blocks, and Switch Expressions — all reached their final, production-ready status simultaneously.

Overview Java 17 includes several platform changes that can break existing code during migration. This article covers four JEPs that affect compatibility: JEP Change Impact 403 Strongly Encapsulate JDK Internals HIGH — breaks libraries using internal APIs 407 Remove RMI Activation LOW — niche feature, deprecated since Java 15 411 Deprecate Security Manager MEDIUM — some applications use SecurityManager 306 Restore Always-Strict Floating-Point LOW — affects numeric edge cases JEP 403: Strongly Encapsulate JDK Internals What Changed In Java 8 and earlier, code could access any JDK internal API via reflection — setAccessible(true) bypassed access controls.

Why Migrate to Java 17? Java 17 is the current recommended enterprise LTS. Key reasons to migrate now: Spring Boot 3.x requires Java 17 — the entire Spring ecosystem is moving here Java 11 extended support ends around 2026 depending on your vendor Java 8 mainstream support ended in 2019; extended support ended 2030 for Oracle JDK but active vulnerability exposure is increasing Language features: Records, Sealed Classes, Text Blocks, Pattern Matching, Switch Expressions — all available in Java 17 Security: Strong JDK encapsulation closes years of internal API exposure used in exploits Recommended Migration Path Java 8 → Java 11 → Java 17 Do not jump directly from Java 8 to Java 17 in one step if your codebase is large or has many third-party dependencies.

Why Migrate Now? Java 21 is the current Long-Term Support (LTS) release, and it is the most feature-rich LTS since Java 8. LTS releases receive security patches and bug fixes for years. Java 11, the previous widely-used LTS, reached its extended support window end depending on your vendor. Java 8 mainstream support ended in 2019. More concretely, Java 21 brings: Virtual Threads — drop-in replacement for platform threads, enabling massive concurrency without reactive rewrites Pattern Matching for switch and records — eliminating entire categories of verbose, error-prone instanceof/cast chains Sequenced Collections — a unified API for ordered collection types Generational ZGC — sub-millisecond GC pauses at any heap size These are not incremental improvements.

Finalized in Java 16 (JEP 394). Available in all Java 16+ releases, including Java 17. Previous previews: Java 14 (JEP 305) and Java 15 (JEP 375). The Problem: The instanceof-Cast Dance Every Java developer has written this pattern: // Java 11 — check, then cast if (obj instanceof String) { String s = (String) obj; // cast is logically redundant System.out.println(s.toUpperCase()); } The instanceof check already verified the type. The cast on the next line is conceptually redundant — the compiler could infer that obj is a String in the if body.

Preview Feature in Java 17 (JEP 406 — First Preview). Requires --enable-preview. This feature evolved through Java 18 (JEP 420), Java 19 (JEP 427), Java 20 (JEP 433), and was finalized in Java 21 (JEP 441). The Java 21 final version has minor syntax differences from this Java 17 preview — documented below. Enabling Preview Features Pattern matching for switch requires --enable-preview in Java 17. Add to your build tool: