JDK-27: hard sell?

The JDK release train is so stable that many do not pay attention anymore! Nonetheless, the new JDK-27 release is there and quite a few things to unpack.

• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3: enhances the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use the javax.net.ssl APIs will benefit from these improved algorithms by default, without change to existing code.

• JEP 523: Make G1 the Default Garbage Collector in All Environments: makes the Garbage-First (G1) garbage collector the default collector in all environments, rather than just server environments. It worth noting that all other collectors are still available and could be specified, only default changes.

• JEP 534: Compact Object Headers by Default: makes compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, thereby reducing heap size, improving deployment density, and increasing data locality.

• JEP 536: JFR In-Process Data Redaction: enhances JDK Flight Recorder (JFR) to redact command-line arguments and the initial values of environment variables and system properties in recordings. Redact this data before it leaves the process, so that sensitive information does not leak.

  The new sub-options redact-key and redact-argument have been introduced, allowing to specify one or more filters that select the command-line arguments, environment variables, and system properties to be redacted.

    java -XX:FlightRecorderOptions:'redact-key=confidential,redact-argument=https://*:*@*' ...
    

Quite a few preview and incubating (vectors!) features have been carried over from the previous releases, notably:

• JEP 538: PEM Encodings of Cryptographic Objects (Third Preview): introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is a preview API feature.

• JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview): enhances pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature.

• JEP 531: Lazy Constants (Third Preview): introduces an API for lazy constants, which are objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility as to the timing of their initialization. This is a preview API feature.

• JEP 533: Structured Concurrency (Seventh Preview): simplifies concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API feature.

• JEP 537: Vector API (12th Incubator): introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations. This is an incubating API feature.

The standard library (to my surprise at least) got only a handful of changes and bug fixes introduced, the most interesting ones are below.

• JDK-8371683: TYPE_USE Annotations on a var Lambda Parameter Are Rejected: following the specification change in Java 20 (JDK-8295807), the following code should be illegal, as TYPE_USE annotation should not be applicable to variable declaration that uses var (including lambda parameter declaration):

  @Retention(value=RUNTIME)
  @Target(value={TYPE_USE})
  @interface Anno {
  }
  
  ...
  
  Function<Integer, String> f = (@Anno var val) -> Integer.toHexString(val);
      

• JDK-8371656: HashMap.putAll() optimizations: some optimizations in the bulk insertion methods.

• JDK-8272758: Improve HttpServer to avoid partial file name matches while mapping request path to context path: the behavior of the JDK built-in com.sun.net.httpserver.HttpServer implementation, when matching an incoming request path to an HttpContext path, was switched from string prefix matching to path prefix matching.

• JDK-8210336: DateTimeFormatter predefined formatters should support short time zone offsets: predefined ISO-8601 formatters that accept zone offsets should support short zone offsets for parsing.

• JDK-8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta): the default time zone returned by TimeZone.getDefault() on Windows now reflects the latest IANA TZ database IDs, aligning with current IANA definition

• JDK-8196182: ServiceLoader.iterator().hasNext()/.next() may throw a LinkageError: the ServiceLoader specifies its iterator methods to throw ServiceConfigurationError "if an error occurs locating, loading or instantiating a service provider".

• JDK-8385924: GZIPInputStream.read() behaves differently on some Java versions: a new system property jdk.util.gzip.tryReadAheadAfterTrailer is introduced to allow applications to control how the java.util.zip.GZIPInputStream behaves when reading the next member in a GZIP stream.

• JDK-8380452: ZipOutputStream::putNextEntry(ZipEntry) throws unspecified IllegalArgumentException for unmappable entry name: updates java.util.zip.ZipOutputStream::putNextEntry(ZipEntry e) to throw ZipException instead of unspecified IllegalArgumentException when an entry name or comment cannot be encoded.

• JDK-8376698: Add Spliterator tests for TreeMap sub-maps: for the subSet from a java.util.TreeSet or a java.util.TreeMap::keySet, if such a set is empty, its spliterator now properly throws NullPointerException for tryAdvance and forEachRemaining.

• JDK-8371748: Remove the (empty) ThreadPoolExecutor.finalize() method: the finalizer in ThreadPoolExecutor has been removed.

• The java.lang.foreign.SegmentAllocator interface was improved with one new method:

  • default MemorySegment allocateFrom(String str, Charset charset, int srcIndex, int numChars)

• The java.lang.Math got three new methods introduced:

  • public static double acosh(double x)
  • public static double asinh(double x)
  • public static double atanh(double x)

• The java.lang.StrictMath mirrored the change:

  • public static double acosh(double x)
  • public static double asinh(double x)
  • public static double atanh(double x)

• Surpring addition to java.lang.String class:

  • public int encodedLength(Charset cs)

• One method was added to java.math.BigDecimal class:

  • public BigDecimal rootn(int n, MathContext mc)

• Quite useful improvements to java.time.format.DateTimeFormatterPatternProvider:

  • public abstract String getDateTimeFormatterPattern(FormatStyle dateStyle, FormatStyle timeStyle, String calType, Locale locale)
  • public abstract String getDateTimeFormatterPattern(String requestedTemplate, String calType, Locale locale)

That was it. Let us take a look which changes went into JVM itself, including garbage collection:

• JDK-8374348: -XX:AOTMode=required as alias for -XX:AOTMode=on: adds -XX:AOTMode=required as an alias to -XX:AOTMode=on (the intent is to deprecate and eventually remove -XX:AOTMode=on).

• JDK-8359706: VM.info and hs_err_pid Logs Now Report Current Open File Descriptor: adds printing of the current open file descriptor count to the VM.info output and hs_err_pid crash logs using native OS calls.

• JDK-8382582: Remove the experimental JVMCI feature: removes JVMCI Compiler Interface. This is pretty disruptive change, using the Graal compiler instead of C2 is not supported anymore.

• JDK-8227106: Rename -XX:InitiatingHeapOccupancyPercent to -XX:G1IHOP: only the G1 garbage collector uses the option -XX:InitiatingHeapOccupancyPercent but it is always available. As such, it was changed to -XX:G1IHOP for consistency and made available only if the G1 collector is available.

• JDK-8363996: The UseCompressedClassPointers Option Is Now Obsolete: UseCompressedClassPointers was deprecated in JDK-25, made obsolete, and its maintaining code was removed as well.

• JDK-8373481: Removal of -noclassgc, -noverify, -verifyremote and -Xverify:none Options: the -noclassgc, -noverify, -verifyremote and -Xverify:none were deprecated in JDK-24 for removal and now are removed.

• JDK-8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc: changes the default values for MinHeapFreeRatio and MaxHeapFreeRatio flags when using the G1 garbage collector. Their new values will not affect Java heap sizing any more unless explicitly set by the user.

• JDK-8380590: Parallel: Improve tenuring-threshold heuristics: tries to make the heuristic bidirectional and based on observed young-gen signals. It should lower the threshold when survivor pressure squeezes eden, and raise it only after a short recovery window when young-gen commit headroom is available.

• JDK-8378331: G1: WeakProcessor IsAlive and KeepAlive closures not handling humongous candidates correctly: these closures now handle humongous candidates properly to allow eager reclaim.

• JDK-8373894: G1: Count evacuation-failed garbage collections in gc cpu usage: fixes one of the causes of the significant distortions in GC behavior.

• JDK-8377561: Parallel: Large allocations cause Full GC storm without heap expansion

• JDK-8381834: Improve TLAB sizing heuristics

Moving on to JDK and tooling, a number of highlights here:

• JDK-8296183: jndiprovider.properties contains properties pointing to non-existing classes: the jndiprovider.properties file was removed from the java.naming module.

• JDK-8371842: Support for CLDR Version 48.2: upgrades the CLDR data in the JDK to version 48.2.

• JDK-8381002: Thread dump should convert longs to json numbers if possible: changed the JSON format thread dump generated by HotSpotDiagnosticMXBean::dumpThreads API and the jcmd Thread.dump_to_file to convert Java longs to JSON numbers instead of strings.

• JDK-8378110: Add -XX: prefix to settings-file flags in RuntimeMXBean.getInputArguments(): the RuntimeMXBean::getInputArguments() method now adds the -XX prefix for arguments passed through a settings file.

• JDK-8377004: Java Launcher incorrectly allows inheriting a package-private main from another package: the proper inheritance rules will be followed when detecting the main methods to invoke.

• JDK-8355522: Remove the `java.locale.useOldISOCodes` system property: the property was introduced for the backward compatibility in JDK-17, deprecated in JDK-25 and now removed.

• JDK-8381511: Remove Obsolete Translation Resources: removes the majority of obsolete translation resource files from the JDK.

• JDK-8369227: Virtual thread stuck in PARKED state

• JDK-8379284: Avoid the need to keep obsolete preview feature constants until bootstrap JDK is upgraded

• JDK-8357439: Added Bash Autocompletion Script for the jcmd Tool: a Bash autocompletion script for the jcmd diagnostic tool has been added.

• JDK-8384164: JFR: Omit command-line arguments for jdk.SystemProcess: to avoid leaking sensitive information from processes running on the same computer, the jdk.SystemProcess event no longer emits command-line arguments.

• JDK-8382740: JFR: Disable jdk.OldObjectSample event for generational ZGC: the JFR event jdk.OldObjectSample is disabled when using generational ZGC.

• JDK-8367584: Implement JEP 536: JFR In-Process Data Redaction: the JVM option -XX:FlightRecorderOptions has been extended with a `help` option that lists the available suboptions.

      java -XX:FlightRecorderOptions:help
      

The list of different security related fixes and enhancements is truly impressive:

• JDK-8372526: Added Support for ZLIB TLS Certificate Compression: implements certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm (see RFC-8879 for more details).

• JDK-8364182: New jcmd Command VM.security_properties Displays Active Security Properties at Runtime:

    jcmd  VM.security_properties
    

• JDK-8347938: Added Support for the Latest ML-KEM and ML-DSA Private Key Encodings: the JDK now encodes ML-KEM and ML-DSA private keys in PKCS #8 format using the DER-encoded ASN.1 CHOICE formats defined in Section 6, "Private Key Format" of RFC-9935 and Section 6, "Private Key Format" of RFC-9881. Two new security properties, jdk.mlkem.pkcs8.encoding and jdk.mldsa.pkcs8.encoding, control the encoding used when generating new keys with a KeyPairGenerator or when translating keys with a KeyFactory.

• JDK-8368692: Restrict Password::readPassword from reading from System.in: introduced a new security property named jdk.security.password.allowSystemIn to control whether JVM can read password from the standard input stream.

• JDK-8374808: New KeyStore and KeyStoreSpi Methods to Retrieve Creation Date as an Instant: new methods have been added to the KeyStore and KeyStoreSpi classes that return the creation dates of alias entries as java.time.Instant values:

  • public Instant KeyStore::engineGetCreationInstant(String alias)
  • public Instant KeyStoreSpi::engineGetCreationInstant(String alias)

• JDK-8369917: Additional Parameter Sets for HSS/LMS: the HSS/LMS signature algorithm now supports the additional parameter sets defined in RFC-9858, in addition to those originally defined in RFC-8554.

• JDK-8378893: X25519 should utilize a larger limb size: the increased limb size will increase performance by reducing the amount of limb operations by ~half when using 51-bit limbs.

• JDK-8384353: SHA3 AVX2 and AVX512 intrinsics and improvements: SHA-3 intrinsics have been optimized in this release for x86_64 systems that support AVX-512. The ML-KEM and ML-DSA algorithms extensively use SHA-3.

• JDK-8377550: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement: TLS 1.3 key agreement has been changed to use the Generic key algorithm for Diffie-Hellman shared secrets instead of the TlsPremasterSecret algorithm.

• JDK-8373426: Removal of ffdhe6144 and ffdhe8192 from the Default List of TLS Named Groups: ffdhe6144 and ffdhe8192 are rarely used groups and don't need to be in the default list.

By and large, JDK-27 is not the release that brings a lot to the table. Still, for many the post-quantum cryptography could be the thing warranting the adoption. All eye towards JDK-28 now.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Unexpected usefulness of the MessageDigest::isEqual method

How one would compare two Strings for equality in Java? There are a few options that come to mind, String::equals or Objects::equals would probably be among those. But for certain, not MessageDigest::isEqual, not even close.

So what gives? No doubts, String::equals is very efficient and returns result as soon as possible. In majority of cases, this is the desired behavior. But what if you compare secrets or alike? For example, tokens, API keys, etc. Not a big deal, right? It turns out it is, your code might be susceptible to so called timing attacks. The gist of it is that comparing two String values is the function of a) their sizes b) how many matching characters they have consequently. The attacker could apply brute force tactics and figure out what the size of the expected secret should be and then, with some patience, guess the characters. All that just by capturing how much time the comparison takes.

How MessageDigest::isEqual helps, you may ask? It actually examines all the bytes of the first argument, as such the calculation time depends only on its length and it does not depend on the length of the second argument (nor the contents of both).

So next time you see the snippet like this

MessageDigest.isEqual(
    token1.getBytes(StandardCharsets.UTF_8), 
    token2.getBytes(StandardCharsets.UTF_8));

where there is seemingly nothing going on related to message digests, you know why.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

JDK-26: incremental improvement

Time for celebration once again: the JDK-26 was released just a few days ago! Although from all perspectives this release looks like incremental improvement (not a feature fest), it is worth paying close attention to.

• JEP 500: Prepare to Make Final Mean Final: issues warnings about uses of deep reflection to mutate final fields. These warnings aim to prepare developers for a future release that ensures integrity by default by restricting final field mutation, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential using --enable-final-field-mutation=module1,module2,... and --illegal-final-field-mutation=allow|warn}debug|deny command line arguments.

• JEP 516: Ahead-of-Time Object Caching with Any GC: enhances the ahead-of-time cache, which enables the HotSpot Java Virtual Machine to improve startup and warmup time, so that it can be used with any garbage collector, including the low-latency Z Garbage Collector (ZGC). Achieve this by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than map them directly into memory in a GC-specific format.

  GC-specific cached objects are mapped directly into memory, while GC-agnostic cached objects are streamed into memory. You can explicitly create a cache whose objects are in the streamable, GC-agnostic format by specifying -XX:+AOTStreamableObjects.

• JEP 517: HTTP/3 for the HTTP Client API: updates the HTTP Client API to support the HTTP/3 protocol, so that libraries and applications can interact with HTTP/3 servers with minimal code change.

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

  Interestingly, JDK does not provide HTTP/3 server implementation (yet), however Netty library, the de facto standard in Java ecosystem for implementing high performance protocol servers (and clients), is supporting HTTP/3 in 4.2 release line.

• JEP 522: G1 GC: Improve Throughput by Reducing Synchronization: increases application throughput when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads.

• JEP 504: Remove the Applet API: removes the Applet API, which was deprecated for removal in JDK 17. It is obsolete because neither recent JDK releases nor current web browsers support applets.

There are a few JEPs that made into JDK-26 as preview features, all of them are carried over from the previous JDK releases.

• JEP 524: PEM Encodings of Cryptographic Objects (2nd Preview): introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is a preview API feature.

• JEP 525: Structured Concurrency (6th Preview): simplifies concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API feature.

• JEP 526: Lazy Constants (2nd Preview): introduces an API for lazy constants, which are objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility as to the timing of their initialization. This is a preview API feature.

  This feature used to be known as stable values (JDK-25) and was renamed to lazy constants to better capture its intended use cases.

• JEP 530: Primitive Types in Patterns, instanceof, and switch (4th Preview): enhances pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview API feature.

• JEP 529: Vector API (11th Incubator): introduces an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations.

Indeed, the list of JEPs is not very impressive, but it does not make JDK-26 less important. There are quite a lot of interesting fixes and improvements in this release.

• JDK-8369432: Add Support for JDBC 4.5 MR: the JDBC 4.5 MR is small update to the JDBC specification and may have an impact on compatibility with some driver implementations.

• JDK-8346944: Update Unicode Data Files to 17.0.0: supports the Unicode Standard version 17.0.

• JDK-8354548: Update CLDR to Version 48.0: upgrades the CLDR data in the JDK to version 48.0.

• JDK-8364993: JFR: Disable jdk.ModuleExport in default.jfc: some applications with lots of code can produce an enormous number of ModuleExport events and associated constant pool data.

• JDK-8364556: JFR: Disable SymbolTableStatistics and StringTableStatistics in default.jfc: there were reports of slow response time due to these two events.

• JDK-8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file: the thread dump generated by the com.sun.management.HotSpotDiagnosticMXBean.dumpThreads(...) and the diagnostic command jcmd <pid> Thread.dump_to_file now includes information about park blocker owner for threads that are parked on java.util.concurrent.locks.AbstractOwnableSynchronizer objects.

• JDK-8212084: G1: Implement UseGCOverheadLimit: the G1 garbage collector now throws an OutOfMemoryError when the garbage collection overhead is more than GCTimeLimit percent (default value 98) and the free Java heap is less than GCHeapFreeLimit percent (default value 2) for five consecutive garbage collections. This feature is enabled by default and can be disabled using the -XX:-UseGCOverheadLimit command line option.

• JDK-8048180: G1: Eager reclaim of humongous objects with references: the G1 garbage collector now eagerly reclaims eligible humongous (very large objects that occupy more than half a heap region) objects containing references.

• JDK-8325467: Support methods with many arguments in C2: the C2 JIT compiler can now compile Java methods with a large number of parameters. Previously, C2 would attempt to compile such methods but bail out, causing the JVM to fall back to C1-compiled code or the interpreter.

• JDK-8366434: THP not working properly with G1 after JDK-8345655: fixes the regression introduced in JDK-25 where on systems configured with the Transparent Huge Pages (THP) mode as madvise, the option -XX:+UseTransparentHugePages does not enable huge pages when running with the default garbage collector G1. The issue preventing the option -XX:+UseTransparentHugePages from enabling THP has been resolved.

• JDK-8371986: Remove the default value of InitialRAMPercentage: removes the default value of InitialRAMPercentage. Now, if the user does not specify an initial Java heap size, the JVM sets the initial heap size to the minimum possible heap size, which equals to MinHeapSize. This improves startup performance for default JVM configurations by reducing internal memory initialization.

• JDK-8368740: Serial: Swap eden and survivor spaces position in young generation: if the heap is almost full, Serial GC will try everything to expand eden in order to satisfy the allocation request. This can cause eden size to grow beyond the limit determined by SurvivorRatio however the new behavior may avoid OutOfMemoryError's in very tight heap situations that would previously often lead to JVM termination.

• JDK-8364638: Refactor and make accumulated GC CPU time code generic: at VM exit -Xlog:cpu now prints a table breaking down VM CPU usage into components.

      [62.719s][info][cpu] === CPU time Statistics =============================================================
      [62.719s][info][cpu] CPUs
      [62.719s][info][cpu] s % utilized
      [62.719s][info][cpu] Process
      [62.719s][info][cpu] Total 410.2789 100.00 6.5
      [62.719s][info][cpu] Garbage Collection 124.8134 30.42 2.0
      [62.719s][info][cpu] GC Threads 124.5082 30.35 2.0
      [62.719s][info][cpu] VM Thread 0.3052 0.07 0.0
      [62.719s][info][cpu] =====================================================================================
      

• JDK-8359110: Log accumulated GC and process CPU time upon VM exit: adds support to log CPU cost for GC during VM exit with -Xlog:gc+cpu.

      [2,430s][info][gc,cpu] GC CPU usage: 22,87% (Process: 26,8926s GC: 6,1491s)
      

• JDK-8369346: Remove default value of and deprecate the MaxRAM flag: removes the default value of the MaxRAM flag so that it only has an effect if a user explicitly sets it; otherwise, ergonomic heap sizing will be based solely on physical memory reported by the operating system. Additionally, the MaxRAM flag should be deprecated.

• JDK-8370814: Deprecate AggressiveHeap: the AggressiveHeap flag, while intended to simplify JVM tuning for memory-intensive applications, introduces ambiguity and maintenance challenges, making it unsuitable as a general-purpose optimization option. The flag is deprecated for removal.

• JDK-8369238: Allow virtual thread preemption on some common class initialization paths: a virtual thread that tries to initialize a class already being initialized by another thread will now, in most cases, be unmounted from its carrier while waiting. Previously, the behavior was to pin the virtual thread to its carrier while waiting for the other thread to execute the class initializer.

• JDK-8366691: JShell should support a more convenient completion: enhances the JShell API with a support for more powerful code completion for JShell snippets, suitable for GUI applications.

• JDK-8330940: Impossible to create a socket backlog greater than 200 on Windows 8+: setting the connection backlog to a value greater than 200 in java.net.ServerSocket, java.nio.channels.ServerSocketChannel, and java.nio.channels.AsynchronousServerSocketChannel is now effective on Windows. Previously it was clamped at 200.

• JDK-8370057: Correct scale handling of BigDecimal.sqrt: changes the preferred scale of java.math.BigDecimal#sqrt to align with IEEE 754.

• JDK-8363972: Lenient parsing of minus sign pattern in DecimalFormat/CompactNumberFormat: the java.text.NumberFormat now allows implementations to parse the minus sign in negative patterns leniently when in lenient mode (java.text.NumberFormat#isStrict() returns false).

• JDK-8357653: Inner classes of type parameters emitted as raw types in signatures: fixes the issue when the code that names an inner class is erroneously classified as raw and as a result is erroneously rejected (example below).

    static abstract class Getters<T> {
        abstract class Getter {
            abstract T get();
        }
    }
  
    static class Usage<T, G extends Getters<T>> {
        public T test(G.Getter getter) {
            return getter.get();       // incompatible types: Object cannot be converted to T
        }
    }
    

• JDK-8369517: Compilation mismatch for equivalent lambda and method reference: fixes the Java compiler behavior when a capture conversion should be applied when deciding if a method reference is compatible with a given function type.

      interface Main {
        interface X>T< {
            X>T< self();
        }
  
        static X>?< makeX() {
            return null;
        }
  
        static >R< X>R< create(Supplier>? extends R< supplier) {
            return null;
        }
  
        static X>X>?<< methodRef() {
            return create(Main::makeX).self();
        }
  
        static X>X>?<< lambda() {
            return create(() -> makeX()).self(); // incompatible types: 
        }
    } 
      

• JDK-7105350: HttpExchange's attributes are the same as HttpContext's attributes: fixes an issue when the com.sun.net.httpserver.HttpExchange attribute map was shared with the enclosing com.sun.net.httpserver.HttpContext.

• JDK-8362561: Remove diagnostic option AllowArchivingWithJavaAgent: some old CDS tests cases use Java agents during java -Xshare:dump execution for injecting Java agents and require the diagnostic -XX:+AllowArchivingWithJavaAgent command line option which can sometimes be abused and produce undesirable side effects.

For more elaborate overview of GC changes, please refer to JDK 26 G1/Parallel/Serial GC changes blog post. Besides just JEP 517, the java.net.http.HttpClient got quite a lot of attention in this JDK release, certainly worth highlighting separately.

• JDK-8367112: HttpClient does not support Named Groups set on SSLParameters: during the setup of new connections, java.net.http.HttpClient now uses the signature schemes and named groups configured on java.net.ssl.SSLParameters when negotiating the TLS handshake. Previously these configured values were ignored.

• JDK-8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody(): java.net.http.HttpClient has been updated to stop sending the Content-Length header on HTTP/1.1 requests using a HTTP methods other than POST or PUT when provided with a HttpRequest.BodyPublisher that reports a contentLength() of zero bytes.

• JDK-8351983: HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute: the java.net.HttpCookie has been updated to correctly handle cookies with both Expires and Max-Age attributes.

• JDK-8208693: HttpClient: Extend the request timeout's scope to cover the response body: the java.net.http.HttpClient request timeout set via java.net.http.HttpRequest.Builder::timeout(...) previously applied only until the response headers were received. Its scope has now been extended to also cover the consumption of the response body, if present.

• JDK-8329829: HttpClient: Add a BodyPublishers.ofFileChannel method: add a new static ofFileChannel(FileChannel channel, long offset, long length) method to java.net.HttpRequest.BodyPublishers to allow an java.net.http.HttpClient request body publisher to upload a certain region of a file.

• Also, java.net.http.HttpRequest got a new method:

  • public <T> Optional<T> getOption(HttpOption<T> option)

Another notable changes in JDK include:

• JDK-8366575: Remove SDP support: InfiniBand SDP (Sockets Direct Protocol) has been obsolete for more than a decade and is no longer maintained on any major platform, and cannot be used on modern systems.

• JDK-8332623: Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte): removes the following terminally deprecated methods from java.net.MulticastSocket:

  • public void setTTL(byte ttl) throws IOException
  • public byte getTTL() throws IOException
  • public void send(DatagramPacket p, byte ttl) throws IOException

  and the following terminally deprecated methods from java.net.DatagramSocketImpl

  • protected void setTTL(byte ttl) throws IOException
  • protected byte getTTL() throws IOException

• JDK-8356557: Update CodeSource::implies API documentation and deprecate java.net.SocketPermission class for removal: deprecates java.net.SocketPermission for removal and removes dependencies on java.net.SocketPermission from java.security.CodeSource#implies(...).

• JDK-8366577: Deprecate java.net.Socket::setPerformancePreferences: deprecates the method setPerformancePreferences in java.net.Socket, java.net.SocketImpl, and java.net.ServerSocket for removal without any replacement.

• JDK-8368226: Remove Thread.stop: removes java.lang.Thread#stop() method.

• JDK-8370387: Remove handling of InterruptedIOException from java.io classes: removes uses of java.io.InterruptedIOException from relevant classes in its package (the class java.io.InterruptedIOException is problematic and is targeted for deprecation and eventual removal).

• JDK-8364361: [process] java.lang.Process should implement Closeable: the addition of java.lang.Process#close() and the implementation of java.io.Closeable and java.lang.AutoCloseable interfaces to java.lang.Process allow for consistent and reliable cleanup.

• JDK-8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat: by using the same algorithm used by java.lang.Double#toString() and java.util.Formatter, the behavior of java.text.DecimalFormat becomes aligned with these and produce comparable outcomes.

• JDK-8362637: Convert java.nio.ByteOrder to an enum: converts java.nio.ByteOrder to an enum for use in switch expressions.

• JDK-8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562: adds a static factory method java.util.UUID#ofEpochMillis(long) to create Version 7 UUIDs as defined in RFC 9562, embedding the supplied Unix time in milliseconds.

• JDK-8368527: JMX: Add an MXBeans method to query GC CPU time: adds a new method to java.lang.management.MemoryMXBean to return the accumulated CPU time in nanoseconds for GC related activity.

  • default long getTotalGcCpuTime()

• JDK-8365675: Add String Unicode Case-Folding Support: adds Unicode standard-compliant case-less comparison methods to the java.lang.String class, enabling and improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

  • public int compareToFoldCase(String str)
  • public boolean equalsFoldCase(String anotherString)

• JDK-8368856: Add a method that performs saturating addition of a Duration to an Instant: adds new java.time.Instant#plusSaturating(Duration) method.

• JDK-8366829: Add java.time.Duration constants MIN and MAX: adds to java.time.Duration two new constants MIN and MAX.

• JDK-8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface: new default methods java.util.Comparator#min(...) and java.util.Comparator#max(...) have been added to the java.util.Comparator interface, which allow finding greater or smaller of two objects (according to this comparator).

• In addition, java.math.BigInteger got two new methods:

  • public BigInteger[] rootnAndRemainder(int n)
  • public BigInteger rootn(int n)

This is pretty much it but we haven't talked about security related changes, it is just about time.

• JDK-8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1): the support of a new stronger MAC algorithm for PKCS#12 defined in RFC 9879 has been implemented.

• JDK-8349732: Add support for JARs signed with ML-DSA: adds support for JARs signed with ML-DSA, based on IETF RFC 9882.

• JDK-8325448: Hybrid Public Key Encryption: implement HPKE (Hybrid Public Key Encryption) as defined in RFC 9180 in the form of a JCE javax.crypto.Cipher.

• JDK-8244336: Restrict algorithms at JCE layer: creates a new security property jdk.crypto.disabledAlgorithms that restricts crypto algorithms at the JCE layer.

• JDK-8359956: Support algorithm constraints and certificate checks in SunX509 key manager: supports TLS algorithm constraints and certificate checks in SunX509 key manager which is currently the default key manager.

• JDK-8361964: Remove outdated algorithms from requirements and add PBES2 algorithms: removes the following algorithms from the list of required algorithms as they are no longer recommended, and should not be in wide usage anymore:

    AlgorithmParameters: DESede
      Cipher:
          DESede/CBC/NoPadding
          DESede/CBC/PKCS5Padding
          DESede/ECB/NoPadding
          DESede/ECB/PKCS5Padding
          RSA/ECB/PKCS1Padding
      KeyGenerator: DESede
      SecretKeyFactory: DESede
  

  Add the following PBES2 algorithms from PKCS#5 v2.1 as new requirements:

      AlgorithmParameters:
          PBEWithHmacSHA256AndAES_128
          PBEWithHmacSHA256AndAES_256
      Cipher:
          PBEWithHmacSHA256AndAES_128
          PBEWithHmacSHA256AndAES_256
      Mac:
          PBEWithHmacSHA256
      SecretKeyFactory:
          PBEWithHmacSHA256AndAES_128
          PBEWithHmacSHA256AndAES_256
          PBKDF2WithHmacSHA256 
    

• JDK-8359395: XML signature generation does not support user provided SecureRandom: adds a new javax.xml.crypto.dsig.XMLSignContext property named jdk.xmldsig.SecureRandom so that users can provide their own java.security.SecureRandom object when generating an XML signature.

• JDK-8353749: Improve security warning when using JKS or JCEKS keystores: the tools and java.security.KeyStore APIs have been updated to warn users when legacy JKS and JCEKS keystores are used, as they use outdated cryptographic algorithms and will be removed in a future release.

• JDK-8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups: the output of -XshowSettings:security:tls command line option has been updated to include the list of enabled named groups and the list of enabled signature schemes used for SSL/TLS/DTLS handshakes.

• JDK-8366364: Return enabled signature schemes with SSLConfiguration#getSSLParameters() call: also enhances -XshowSettings:security:tls command line option to show the enabled signature schemes.

• JDK-8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements: delivers new intrinsics using AVX2 instructions on x86_64 platforms for the ML-DSA signature algorithm in the SUN security provider. This feature also improves the existing AVX512 intrinsics for the ML-DSA algorithm. This optimization is enabled by default on supporting x86_64 platforms and may be disabled by providing the -XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics command line options.

If you look for a bit more in-depth overview of the security related changes, please check out JDK 26 Security Enhancements blog post.

To summarize, the gems of JDK-26 release, in my opinion, are JEP 522: G1 GC: Improve Throughput by Reducing Synchronization, JEP 517: HTTP/3 for the HTTP Client API, and JDK-8369238: Allow virtual thread preemption on some common class initialization paths. Those are truly game changing enhancements for quite a wide audience of applications and services. Java continues to impress!

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.