Java 26 — All New Features, Removals & Previews

---

Consider becoming a paid subscriber for as low as $1.6/mo (with an annual subscription) and support the work :)

Still not convinced? Check out the details of the past work

---

1. HTTP/3 support in HttpClient

   1. Java 26 adds a new version enum:

      HttpClient.Version.HTTP_3

   2. This allows HttpClient to negotiate and use HTTP/3. HTTP/3 is not an evolution of HTTP/2 over TCP.It uses a completely new transport.

   3. HTTP/3 uses QUIC over UDP → not upgradable from HTTP/1.1 or HTTP/2.

   4. Connection-level version negotiation is non-trivial.

   5. API surface change is tiny; complexity is under the hood.

      HttpClient client = HttpClient.newBuilder()
          .version(HttpClient.Version.HTTP_3)
          .build();

   When to use

   • Latency-sensitive apps.

   • Packet-loss-heavy networks (QUIC handles loss better).

   • Services that already support HTTP/3 (e.g., Cloudflare, Google).

2. Prepare to Make Final Mean Final

   1. Its main goal is to restore the “immutability guarantee” of final fields by default. In other words, make it so that once a final field is assigned (in a constructor or static initializer), it can’t be overwritten via reflection and related mechanisms.

   2. In Java, since JDK 5, “deep reflection” — using java.lang.reflect.Field.setAccessible(true) + Field::set(...) — has allowed code to override the final guarantee: even a final field can be changed at runtime.

   3. That undermines the semantic meaning of final: for correctness, reasoning about immutability, thread-safety, etc. Also undermines certain optimizations (like constant-folding) the JVM might perform under the assumption that final fields don’t change.

   4. JEP 500 considers the fact that allowing such unconstrained mutation was a “poor choice” and wants to align with the stricter immutability model already used for newer constructs (e.g. records, hidden classes, etc.)

   5. From JDK 26, by default, if code uses reflection (or other deep reflection APIs) to mutate a final field, the JVM will now emit a warning at runtime (instead of silently allowing it).

   6. The warning is intended to notify developers of code paths that mutate final fields, to give time to migrate.

   7. In future JDK versions, the plan is for such mutation to be disallowed by default — i.e. Field::set(...) on a final field will throw an exception rather than succeed (unless explicitly allowed)

3. Remove the Applet API

   1. JEP 504 proposes to remove the entire java.applet API from the standard Java SE platform.

   2. It was marked Completed and targeted for JDK 26.

   3. The Applet API was deprecated for removal back in JDK 17 (2021).

   4. Web browsers no longer support Java applets — the plugin model that allowed applets to run in browsers is largely dead.

4. Lazy Constants (Second Preview)

   1. JEP 526 introduces a new API: java.lang.LazyConstant<T> — a holder for a value that is computed lazily (on first demand) but then becomes immutable (“constant”) thereafter.

   2. Lazy constants are treated by the JVM as “true constants,” enabling many of the same performance and optimization benefits that final fields enjoy (constant-folding, inlining, etc.) once initialized.

   3. Compared to a plain final field, lazy constants give flexibility in when initialization happens — instead of requiring initialization at construction or class-load time.

   4. Using final fields give immutability — but final forces eager initialization (at object creation or class initialization).
      In many real-world cases (e.g., heavy resources: loggers, configs, caches, service clients,) you may want to delay initialization until first use to save startup costs.

      private static final LazyConstant<Logger> LOG =
          LazyConstant.of(() -> Logger.create(MyService.class));

   5. JEP 526 is a refinement / second preview of what had been previously proposed under JEP 502 (“Stable Values”). Changes include:

      1. Renamed the API from StableValue → LazyConstant — a name better aligned with the high-level use case.

      2. Removed lower-level methods (orElseSet, setOrThrow, trySet) from the API — simplifying it to just “factory + get” style.

5. Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

   1. JEP 530 makes primitive types (int, long, float, double, boolean, etc.) first‑class participants in Java’s pattern matching, instanceof, and switch

   2. It’s a preview language feature in JDK 26.

   3. Historically, pattern matching, instanceof, and switch supported only reference types (objects), or a limited subset of primitive-like types; this JEP removes that restriction.

   4. Primitive Type Patterns in instanceof, switch, Pattern Matching

      You can now write:

      if (x instanceof int i) {
          // i is bound as int
      }
      
      switch (someLongValue) {
        case 1L -> ...
        case long l -> ...
      }

   5. instanceof Supports Primitive Types

      Instead of only instanceof SomeClass, you can test primitive‑to‑primitive safe conversions:

      int i = ...;
      if (i instanceof byte b) {  // tests if i can be losslessly cast to byte
          // b is byte
      }

   6. switch Works on All Primitive Types

6. Structured Concurrency (Sixth Preview)

   1. JEP 525 proposes a new API for structured concurrency in Java — grouping related concurrent tasks (sub‑tasks) into a single larger “unit of work,” rather than letting each thread/future run independently.

   2. The goal: simplify concurrent programming, improve error handling and cancellation, make concurrency more reliable and observable.

   3. This is the sixth preview (i.e. still not “final” / fully stable) — meaning: available in JDK 26, but API and semantics might evolve.

   4. Example code:

      

      • Scope cancels remaining tasks automatically if any task fails.

      • ShutdownOnFailure ensures clean error handling.

      • No manual thread pool management.

7. Ahead-of-Time Object Caching with Any GC

   • JEP 516 extends the existing Ahead‑Of‑Time (AOT) cache (from earlier “class loading & linking ahead‑of-time” support) so that cached Java objects (not just classes) can be used with any garbage collector — including low‑latency ones like ZGC.

   • In previous JDKs, AOT cache stored objects in a GC‑specific binary layout; that meant the cache only worked reliably with certain GCs (Serial, Parallel, G1). That prevented using AOT cache + ZGC simultaneously.

   • Now, the cache can optionally use a new GC-agnostic format: instead of mapping memory directly, the JVM will stream and materialize objects at startup. That means regardless of the active garbage collector, the cache can still be used.

8. JEP 522 — G1: Improve Throughput by Reducing Synchronization

   1. JEP 522 aims to improve throughput and latency for applications using G1 by reducing the synchronization overhead between application (mutator) threads and GC threads.

   2. It changes the write‑barrier / card‑table mechanism inside G1, replacing the old heavily synchronized approach with a dual‑card‑table + swap strategy — letting application threads update one card table lock‑free while GC/optimizer threads process the other

9. PEM Encodings of Cryptographic Objects (Second Preview)

   1. JEP 524 adds a new, standardized API for converting Java crypto objects (keys, certificates, CRLs, etc.) to and from the textual PEM format — the classic Base64 + header/footer format used widely in TLS, SSH, cert files, etc.

   2. The API is a preview in JDK 26 (second preview) — meaning you must opt in with preview flags to use it.

   3. Historically, if you had a certificate or key in Java (like X509Certificate, PrivateKey, PublicKey, etc.) and wanted to export it as PEM (to write to file, send over network, interoperate with OpenSSL/SSH/other systems), there was no built-in Java API — you had to manually base64‑encode DER or use external libraries.

   4. PEM is extremely widely used (TLS certs, key stores, SSH, config files, certificates, CRLs, etc.). By adding native PEM support, Java becomes far more interoperable and convenient for security, devops, tooling, and integration workflows

      

      ---

Consider becoming a paid subscriber for as low as $1.6/mo (with an annual subscription) and support the work :)

Still not convinced? Check out the details of the past work

---

Check out more Java/Spring Boot Interview Coding Questions

Check out Java/Spring Boot Quizzes

Check out Top Java and Spring Boot Blogs