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.

Chasing Java's release train, from 8 to 16. Part 2: The race to the next LTS release.

In the first part we thoroughly went through the massive amount of features delivered in scope of JDK-9. Nevertheless, this release was always considered as being transitional, with little or no adoption expected. It has a mission to kick off the race towards next LTS release, JDK-11.

JDK 10

JDK-10, the first release followed the six months cadence cycle, brought a number of new features into the language and JVM itself. Let us take a look at the most interesting ones from the developer's perspective.

• JEP-286: Local-Variable Type Inference: enhances the Java language to extend type inference to declarations of local variables with initializers. It allows the reserved type name var to be accepted in place of manifest types for local variable declarations with initializers, enhanced for-loop indexes, and index variables declared in traditional for loops:

    var listOfMaps = new ArrayList<Map<String, String>>();
    

  Or, enforcing immutability:

    final var listOfMaps = new ArrayList<Map<String, String>>();
    

  If used carefully, the local-variable type inference leads to more compact and concise code, drastically improving its readability, like for example within try-with-resources blocks or loops.

          try (var out = new ByteArrayOutputStream()) {
              out.write(...);
          }
      

          var listOfMaps = new ArrayList<Map<String, String>>();
          for (var e: listOfMaps) {
              // ...
          }
      

  The counterexample would be to strip valuable type information altogether by combining var and diamond operator <>, likely abusing the feature.

    var listOfMaps = new ArrayList<>();
    

  The fair amount of controversy and confusion around local-variable type inference resulted into publication of the FAQ for JEP 286 which I would highly recommend to read over.

• JEP-316: Heap Allocation on Alternative Memory Devices: enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user. The new flag -XX:AllocateHeapAt=<path> has been added to support such memory device(s).

• JEP-310: Application Class-Data Sharing: to improve startup and footprint, extends the existing Class-Data Sharing ("CDS") feature to allow application classes to be placed in the shared archive. By and large, Class-Data Sharing is probably the least known feature of JDK (the story goes back to JavaSE 5.0!) which nonetheless is quite handy in many circumstances and could significantly reduce the application startup time (obviously it depends a lot on your application). In scope of this JEP, there are 3 steps to take:

  1. Determine the classes to archive:

            $ java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=app.lst -cp app.jar AppMain
            

  2. Create the AppCDS archive:

     $ java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=app.lst -XX:SharedArchiveFile=app.jsa -cp app.jar
            

     Please note that we do not launch the application but just provide the complete classpath instead.

  3. Use the AppCDS archive:

     $ java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=app.jsa -cp app.jar AppMain
         

  One of the limitation of this JEP is that CDS cannot archive classes from user-defined modules (such as those specified in --module-path) but the good news are that CDS will get more improvements along JDK-12 and JDK-13 releases, stay tuned.

• JEP-319: Root Certificates: provides a default set of root Certification Authority (CA) certificates in the JDK. Essentially, it means the cacerts keystore will be pre-populated with a set of root certificates issued by the CAs of Oracle's Java SE Root CA Program as such reducing the differences between OpenJDK and Oracle JDK builds.

• JEP-322: Time-Based Release Versioning: revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models. The suggested version number format is:

  [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*
  

  The version number might be possibly followed by pre-release, build, and other optional information. This new semantics of version numbers is certainly working well so far.

• JEP-307: Parallel Full GC for G1: improves G1 worst-case latencies by making the full GC parallel.

• JEP-312: Thread-Local Handshakes: introduces a way to execute a callback on threads without performing a global VM safepoint. Make it both possible and cheap to stop individual threads and not just all threads or none. The feature was controlled by new flag -XX:ThreadLocalHandshakes (default value true) which however was deprecated in JDK-13 since turning it off became not viable from the performance perspective.

• JEP-304: Garbage-Collector Interface: improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface. The motivation is very simple: make it much easier to implement new collectors and in fact a number of new GC collectors would greatly benefit from this change in later releases.

• JEP-313: Remove the Native-Header Generation Tool (javah): removes the javah tool from the JDK since it has been superseded by superior functionality in javac (JDK-7150368).

• JEP-317: Experimental Java-Based JIT Compiler: enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform. Sadly, the story of Graal in OpenJDK comes to the end in JDK-17.

• Multiple Collectors enhancements to deal with unmodifiable collections:

  • static <T> Collector<T,?,List<T>> toUnmodifiableList()
  • static <T> Collector<T,?,Set<T>> toUnmodifiableSet()
  • static <T,K,U> Collector<T,?,Map<K,U>> toUnmodifiableMap(Function, Function)
  • static <T,K,U> Collector<T,?,Map<K,U>> toUnmodifiableMap(Function, Function, BinaryOperator)

• The List got a new static method:

  • static <E> List<E> copyOf(Collection<? extends E> coll)

• The Set got a new static method:

  • static <E> Set<E> copyOf(Collection<? extends E> coll)

• The Map got a new static method:

  • static <K,V> Map<K,V> copyOf(Map<? extends K,? extends V> map)

• The family of Optional classes (OptionalDouble, OptionalInt, OptionalLong) got a new method:

  • T orElseThrow()

• The JarFile, along with JarEntry, are finally capable to provide proper support of the multi-release JARs, introduced in JDK-9:

  • Stream<JarEntry> versionedStream()
  • String getRealName()

• The Channels class got two new overloads of the existing static methods:

  • static Reader newReader(ReadByteChannel, Charset)
  • static Writer newWriter(WriteByteChannel, Charset)

• The MethodType was enriched with:

  • Class<?> lastParameterType()

• The Reader got quite handy new method:

  • long transferTo(Writer out) throws IOException

• A new method was introduced into FileStore class:

  • long getBlockSize() throws IOException

• A number of new additions went into StampedLock class in a form of static methods:

  • static boolean isLockStamp(long stamp)
  • static boolean isOptimisticReadStamp(long stamp)
  • static boolean isReadLockStamp(long stamp)
  • static boolean isWriteLockStamp(long stamp)

• The Version class was enhanced to reflect the JEP-322: Time-Based Release Versioning changes:

  • int feature()
  • int interim()
  • int update()
  • int patch()

• After many years, it became possible to get a PID of the running Java virtual machine using the APIs from standard library, thanks to the new method added to RuntimeMXBean:

  • long getPid()

• The ThreadMXBean was extended with new overloaded methods:

  • ThreadInfo[] dumpAllThreads(boolean lockedMonitors, boolean lockedSynchronizers, int maxDepth)
  • ThreadInfo[] getThreadInfo(long[] ids, boolean lockedMonitors, boolean lockedSynchronizers, int maxDepth)

• Minor by handy addition to DateTimeFormatter:

  • DateTimeFormatter localizedBy(Locale locale)

Undoubtedly, JDK-10 release has quite moderate amount of features comparing to JDK-9, but every one of those was delivered much faster, thanks to the new release cycle.

JDK 11

The first LTS release of the JDK following the new schedule, JDK-11, had seen the light in 2018, six month after JDK-10 release. It finally brought a long awaited stability and established a new baseline in post JDK-9 world. It also included a number of features.

• JEP-327: Unicode 10: upgrades existing platform APIs to support version 10.0 of the Unicode Standard. In summary, Unicode 10 adds 8,518 characters, for a total of 136,690 character, notably:

  • Bitcoin sign
  • 56 emoji characters
  • A set of Typicon marks and symbols

• JEP-331: Low-Overhead Heap Profiling: provides a low-overhead way of sampling Java heap allocations, accessible via JVMTI. The JEP brings significant improvements into troubleshooting application memory issues by capturing the call site for particular allocations.

• JEP-332: Transport Layer Security (TLS) 1.3: implements version 1.3 of the Transport Layer Security (TLS) Protocol, as per RFC-8446.

• JEP-329: ChaCha20 and Poly1305 Cryptographic Algorithms: implements the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC-7539. Additionally, the ChaCha20-Poly1305 is opening a door to use AEAD-based cipher suites along with TLS 1.3, nicely complementing JEP-332.

• JEP-181: Nest-Based Access Control: introduces nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods. The best way to understand the changes delivered by this JEP is to look at one of the examples.

  public class Outer {
      public static class Inner {
          public void print(Outer o) {
              System.out.println("Inner");
              o.print();
          }
      }
      
      private void print() {
          System.out.println("Outer");
      }
  }
  

  The nested Inner class, the logical part of the Outer class, has access to its private methods. How is it possible? The compiler would generate the bridge methods for you, visible in bytecode.

  $ javap target/classes/com/example/Outer.class
  Compiled from "Outer.java"
  
  public class com.example.Outer {
    public com.example.Outer();
    public static void main(java.lang.String[]);
    static void access$0(com.example.Outer);
  }
  

  Now, when you compile the same class using JDK-11, the first thing you will notice is that bridge method access$0 is gone.

  $ javap target/classes/com/example/Outer\$Inner.class
  Compiled from "Outer.java"
  
  public class com.example.Outer$Inner {
    public com.example.Outer$Inner();
    public void print(com.example.Outer);
  }
  

  Besides changes in JVM and bytecode, there are a number of new methods added to Class class to reflect the concept of nests and nestmates:

  • Class<?> getNestHost()
  • boolean isNestmateOf(Class<?> c)
  • Class<?>[] getNestMembers()

  For existing applications and/or libraries, these changes should come at no risk unless access bridge methods are explicitly exploited (by all means, doubtful idea in the first place).

• JEP-321: HTTP Client (Standard): standardizes the incubated HTTP Client API introduced in JDK-9, via JEP-110, and updated in JDK-10. The API is consolidated under the java.net.http package and consists of:

  • class HttpClient
  • class HttpHeaders
  • class HttpRequest
  • class HttpRequest.BodyPublishers
  • class HttpResponse.BodyHandlers
  • class HttpResponse.BodySubscribers

  The APIs are concise and easy to use, the snippet below is a convincing example of how intuitive it is (you probably have seen this builder style in many other HTTP clients out there).

          final HttpClient client = HttpClient
              .newBuilder()
              .version(Version.HTTP_2)
              .connectTimeout(Duration.ofMillis(500))
              .followRedirects(Redirect.NEVER)
              .build();
  
          final HttpRequest request = HttpRequest.newBuilder()
              .POST(BodyPublishers.ofString("...", StandardCharsets.UTF_8))
              .uri(URI.create("https://..."))
              .header("Content-Type", "application/json")
              .build();
  
          final Stream<String> lines =  client
              .send(request, BodyHandlers.ofLines())
              .body();
  
          // ...
        

  Not to forget the asynchronous flavor, based on CompletableFutures.

          final CompletableFuture<Stream<String>> lines =  client
              .sendAsync(request, BodyHandlers.ofLines())
              .thenApply(HttpResponse::body);
              
          // ...
        

  And obviously, the reactive style, using the APIs introduced by JEP-266 in JDK-9:

          final Subscriber<String> subscriber = ...;
          final CompletableFuture<HttpResponse<Void>> response = client
              .sendAsync(request, BodyHandlers.fromLineSubscriber(subscriber));
              
          // ...
        

  The HTTP Client supports HTTP/1.1, HTTP/2 (HTTP/2 is the default preferred protocol, and the implementation seamlessly fallbacks to HTTP/1.1 if necessary) and Websockets. The Introduction to the Java HTTP Client is a good starting point to quickly surface the capabilities of the APIs.

• JEP-323: Local-Variable Syntax for Lambda Parameters: allows var to be used when declaring the formal parameters of implicitly typed lambda expressions. This rather small JEP delivers a substantial convenience to labmda expressions.

      final Comparator<String> comparator = (@Nonnull var s1, @Nonnull var s2) -> {
          return ...;
      };
      

  A lambda expression may be implicitly typed, nothing new here, however when you want to decorate its parameters with annotations, it used to require providing the explicit types. With this JEP, not anymore, the var could be used instead. Please note that an implicitly typed lambda expression must use var for all its formal parameters or for none of them.

• JEP-328: Flight Recorder: provides a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM. Flight Recorder has existed for many years and was previously a commercial feature of the Oracle JDK but since JDK-11, it has been open-sourced (and backported to JDK-8). The Flight Recorder command line tool, jfr, which appeared only in JDK-12, was also backported to JDK-11 and is available as of 11.0.6 release. The Flight Recorder could be activated in a different ways:

  • Using JVM command line arguments:

    $ java -XX:StartFlightRecording=settings=profile,duration=6m,name=app-startup,dumponexit=true,filename=/var/log/jfr/app-startup.jfr ...

  • Using jcmd command line tool:

        $ jcmd <pid> JFR.start settings=profile duration=6m name=app-startup
        $ jcmd <pid> JFR.dump filename=app-startup.jfr
        $ jcmd <pid> JFR.stop

  • Using JDK Mission Control

  The Flight Recorder recordings could be visualized in JDK Mission Control or analyzed from the command line using jfr tool. To be fair, these days the Flight Recorder is a primary go-to tool for troubleshooting JVM applications in production.

• JEP-330: Launch Single-File Source-Code Programs: enhances the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques. Who would have thought that one day Java would replace your favorite shell scripts? Well, since JDK-11 you could!

  • Launch a class declared in a source file:

    $ java MyScript.java

  • A shebang file to invoke the Java launcher using source-file mode:

    #!/path/to/java --source <version>

    Please note that in this case the file should not be named as a Java source file (i.e. it should not be a file whose name ends with .java)

  The JEP inspired a number of innovative projects, like jbang f.e., to simplify launching .java files from literally anywhere.

• JEP-320: Remove The Java EE and CORBA Modules: removes the Java EE and CORBA modules from the Java SE Platform and the JDK. The following modules have been removed:

  • java.xml.ws: replacement javax.xml.ws:jaxws-api, javax.xml.soap:javax.xml.soap-api, javax.xml:webservices-api
  • java.xml.ws.annotation: replacement javax.annotation:javax.annotation-api
  • java.xml.bind: replacement javax.xml.bind:jaxb-api
  • java.activation: replacement javax.activation:javax.activation-api
  • java.corba: replacement JacORB
  • java.transaction: replacement javax.transaction:javax.transaction-api

  Since Java EE has been superseded by Jakarta EE, all most recent replacements could be found under new Jakarta brand.

• JDK-8250784: Shenandoah: A Low-Pause-Time Garbage Collector: the Shenandoah GC has been backported to JDK-11 and is available in most distributions since 11.0.9 release.

• JDK-8191369: NMT: Enhance thread stack tracking: great improvement to native memory tracking.

• Probably, the String class had the largest number of new API methods added:

  • boolean isBlank()
  • Stream<String> lines()
  • String repeat(int count)
  • String strip()
  • String stripLeading()
  • String stripTrailing()

• The family of Optional classes (OptionalDouble, OptionalInt, OptionalLong) got a single new method:

  • boolean isEmpty()

• The Pattern has gotten one more method to support Predicate for matches, exceptionally convenient:

  • Predicate<String> asMatchPredicate()

• The Predicate in turn could now be negated:

  • static <T> Predicate<T> not(Predicate<? super T> target)

• The ByteArrayOutputStream could write the complete content now:

  • void writeBytes(byte[] b)

• The InputStream got a few additions:

  • static InputStream nullInputStream()
  • byte[] readNBytes(int len) throws IOException

• The OutputStream was also not left out:

  • static OutputStream nullOutputStream()

• The Reader followed the same route:

  • static Reader nullReader()

• As well as the Writer:

  • static Writer nullWriter()

• The CharSequence was enriched with lexicographical comparison:

  • static int compare(CharSequence cs1, CharSequence cs2)

• A whole family of buffer classes got the mismatch detection support:

  • ByteBuffer was added int mismatch(ByteBuffer that)
  • CharBuffer was added int mismatch(CharBuffer that)
  • DoubleBuffer was added int mismatch(DoubleBuffer that)
  • FloatBuffer was added int mismatch(FloatBuffer that)
  • LongBuffer was added int mismatch(LongBuffer that)
  • ShortBuffer was added int mismatch(ShortBuffer that)

• The SelectionKey got a few atomic operations:

  • int interestOpsOr(int ops)
  • int interestOpsAnd(int ops)

• The Selector had a number of overloaded variants introduced:

  • int select(Consumer<SelectionKey> action) throws IOException
  • int select(Consumer<SelectionKey> action, long timeout) throws IOException
  • int selectNow(Consumer<SelectionKey> action) throws IOException

• The Files utility class became even more useful:

  • static String readString(Path path) throws IOException
  • static String readString(Path path, Charset cs) throws IOException
  • static Path writeString(Path path, CharSequence csq, OpenOption... options) throws IOException
  • static Path writeString(Path path, CharSequence csq, Charset cs, OpenOption... options) throws IOException

• In the same vein, the Path class had a few factory methods introduced:

  • static Path of(String first, String... more)
  • static Path of(URI uri)

• A new default method was added to Collection interface, complementing other favors:

  • default <T> T[] toArray(IntFunction<T[]> generator)

• The TimeUnit had a new conversion option:

  • long convert(Duration duration)

• The PriorityQueue was enhanced with the implementation of:

  • void forEach(Consumer<? super E> action)
  • boolean removeIf(Predicate<? super E> filter)
  • boolean removeAll(Collection<?> c)
  • boolean retainAll(Collection<?> c)

• Consequently, the PriorityBlockingQueue was enhanced with the implementation of:

  • void forEach(Consumer<? super E> action)
  • boolean removeIf(Predicate<? super E> filter)
  • boolean removeAll(Collection<?> c)
  • boolean retainAll(Collection<?> c)

• Multiple enhancements went into ByteBuffer support by Deflater:

  • void setInput(ByteBuffer input)
  • void setDictionary(ByteBuffer dictionary)
  • int deflate(ByteBuffer output)
  • int deflate(ByteBuffer output, int flush)

• ... and by Inflater:

  • void setInput(ByteBuffer input)
  • void setDictionary(ByteBuffer dictionary)
  • int inflate(ByteBuffer output) throws DataFormatException

It worth to note that JDK-11 had introduced two new garbage collectors, ZGC and Epsilon, both were marked as experimental. We are going to get back to those in the upcoming posts while discussing more recent JDK releases.

So, where are we today? The JDK-11 slowly but steadily getting more adoption as more and more projects migrate off the JDK-8. Nonetheless, the majority are still on JDK-8 and in my opinion, there are no reasons to expect drastic changes of the balance within next couple of years. But this is another story ...