JDK-20: the most boring JDK release yet?

Still hot off the press, JDK-20 is out! These are terrific news, but what about exciting new features? Although a number of JEPs made it into the release, all of them are either preview or incubation features:

• JEP-429: Scoped Values (Incubator): introduces scoped values, which enable the sharing of immutable data within and across threads. They are preferred to thread-local variables, especially when using large numbers of virtual threads.

• JEP-432: Record Patterns (Second Preview): enhances the Java programming language with record patterns to deconstruct record values. Record patterns and type patterns can be nested to enable a powerful, declarative, and composable form of data navigation and processing.

• JEP-433: Pattern Matching for switch (Fourth Preview): enhances the Java programming language with pattern matching for switch expressions and statements. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely.

  If you keen to learn more, please check out Using Pattern Matching publication, a pretty comprehensive overview of this feature.

• JEP-434: Foreign Function & Memory API (Second Preview): introduces an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.

• JEP-436: Virtual Threads (Second Preview): introduces virtual threads to the Java Platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.

• JEP-437: Structured Concurrency (Second Incubator): simplifies multithreaded programming by introducing an API for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.

• JEP-438: Vector API (Fifth Incubator): introduces an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.

The pessimists may say this is the most boring release of JDK yet, but the optimist would argue that this is the calm before the storm (yes, I am talking about the next LTS release later this year, JDK-21). Nonetheless, there are quite a few notable changes to look at.

• JDK-8283093: JMX connections should default to using an ObjectInputFilter: enables RMI object filtering for JMX by default, by giving a default value to the existing management.properties setting, com.sun.management.jmxremote.serial.filter.pattern. The intent is to limit possible misuse of a JMX connection.

• The ability to stop, suspend, or resume a thread with the corresponding Thread.stop(), Thread.suspend() or Thread.resume() methods have been eliminated. Those methods have been degraded to throw a java.lang.UnsupportedOperationException exception as per JDK-8249627: Degrade Thread.suspend and Thread.resume and JDK-8289610: Degrade Thread.stop.

• JDK-8293590: Some syntax checks performed by URL.openConnection() could be performed earlier, at URL construction: previously, some of the parsing and validation actions performed by the URLStreamHander implementations were delayed until URLStreamHandler::openConnection or URLConnection::connect calls. Starting from JDK-20, some of these checks are performed earlier, at construction time, when URLStreamHandler::parseURL is called. A new JDK system property jdk.net.url.delayParsing can be specified on the command line to revert to the previous behavior.

• JDK-8292698: Improve performance of DataInputStream

• JDK-8297609: Add application/wasm MIME type for wasm file extension: adds application/wasm as a MIME type for WebAssembly mapping in the default shipped with the JDK content-types.properties file (for the reference, please check https://www.iana.org/assignments/media-types/application/wasm).

• JDK-8295803: Console should be usable in jshell and other environments

• JDK-8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass

• JDK-8254711: Add java.security.Provider.getService JFR Event: adds an event each time a JCE cryptographic service for a specific algorithm is requested and/or used.

• JDK-8291753: Add JFR event for GC CPU Time and JDK-8292373: Add JFR event for GC CPU Time (other GCs): adds a JFR event which includes same information through GCTraceCPUTime.

The standard library was the one benefited the most in JDK-20 release, let us take a closer look at what has changed:

• The java.io.BufferedInputStream got a specialized implementation for long transferTo(OutputStream out) throws IOException

• The java.io.PushbackInputStream got a specialized implementation for long transferTo(OutputStream out) throws IOException

• The java.io.SequenceInputStream got a specialized implementation for long transferTo(OutputStream out) throws IOException

• The java.lang.Float got two new conversion methods:

  • static float float16ToFloat(short floatBinary16)

  • static short floatToFloat16(float f)

• The java.lang.reflect package was enhanced with:

  • A new enum java.lang.reflect.AccessFlag

  • A new enum java.lang.reflect.ClassFileFormatVersion

  • The java.lang.reflect.Field got a new method:

    • Set<AccessFlag> accessFlags()

  • The java.lang.reflect.Member got a new method:

    • Set<AccessFlag> accessFlags()

  • The java.lang.reflect.Parameter got a new method:

    • Set<AccessFlag> accessFlags()

• The java.lang.Class class got a new method as well:

  • Set<AccessFlag> accessFlags()

• A new method was added to java.lang.module.ModuleDescriptor class:

  • Set<AccessFlag> accessFlags()

• The java.net.URL was enhanced with a factory method:

  • static URL of(URI uri, URLStreamHandler handler) throws MalformedURLException

• A new methods found their way into java.nio.file.spi.FileSystemProvider:

  • <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)

  • boolean exists(Path path, LinkOption... options)

• As part of JDK-8297648: j.u.concurrent updates for JDK 20, couple of classes where enriched with new methods:

  • The java.util.concurrent.ForkJoinPool has gotten:

    • <T> ForkJoinTask<T> externalSubmit(ForkJoinTask<T> task)

  • The java.util.concurrent.ForkJoinWorkerThread has gotten:

    • int getQueuedTaskCount()

• A long standing bug JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) Export has been finally fixed by providing overrides in java.util.IdentityHashMap for:

  • boolean remove(Object key, Object value)

  • boolean replace(K key, V oldValue, V newValue)

• A couple of changes touched javax.net.ssl.SSLParameters class:

  • String[] getNamedGroups()

  • void setNamedGroups(String[] namedGroups)

• The improvements made inside java.util.regex package came as a pleasant surprise, those are related to named groups (JDK-8292872: MatchResult should provide values of named-capturing groups):

  • The java.util.regex.Matcher class got new methods:

    • boolean hasMatch()

    • Map<String, Integer> namedGroups()

  • The interface java.util.regex.MatchResult also got new methods:

    • default int end(String name)

    • default String group(String name)

    • default boolean hasMatch()

    • default Map<String, Integer> namedGroups()

    • default int start(String name)

• The java.util.zip.ZipInputStream introduces overrides for methods:

  • int read() throws IOException

  • byte[] readAllBytes() throws IOException

  • byte[] readNBytes(int len) throws IOException

  • int readNBytes(byte[] b, int off, int len) throws IOException

  • void skipNBytes(long n) throws IOException

  • long transferTo(OutputStream out) throws IOException

• A couple of new public constructors were introduced into the java.security.InvalidParameterException class:

  • InvalidParameterException(String msg, Throwable cause)
  • InvalidParameterException(Throwable cause)

The garbage collectors have got a considerable chunk of improvements (especially G1), covered by JDK 20 G1/Parallel/Serial GC changes in great details. To highlight just a few:

• JDK-8210708: Use single mark bitmap in G1: G1 native memory footprint has been reduced significantly by removing one of the mark bitmaps spanning the entire Java heap. Please check the brilliant Concurrent Marking in G1 article for deep technical dive.

• JDK-8292654: G1 remembered set memory footprint regression after JDK-8286115: fixes the previously introduced regression that caused significantly increased memory usage in some benchmarks.

• JDK-8256265: G1: Improve parallelism in regions that failed evacuation

• JDK-8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal

• JDK-8297247: Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1: adds Remark and Cleanup time to a G1 JMX bean.

From the security perspective, it worth mentioning these changes:

• JDK-8256660: Disable DTLS 1.0 by default: disables DTLS 1.0 by default by adding "DTLSv1.0" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

• JDK-8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation: introduces LDAP-specific factories filter (defined by jdk.jndi.ldap.object.factoriesFilter property) and RMI-specific factories filter (defined by jdk.jndi.rmi.object.factoriesFilter property). The new factory filters are consulted in tandem with the jdk.jndi.object.factoriesFilter global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.

This releases proves one more time that boring is not always bad. If you want to learn more about these (and other) features in JDK-20, I would highly recommend going over Java 20 🥱 guide.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Project Loom in JDK-19: the benefits but with quirks

A few months have passed already since JDK-19 release, which we talked about previously in details. More and more developers are switching to JDK-19, turning their heads towards Project Loom and starting to play with virtual threads and structured concurrency (despite the incubation / preview status of these features). And it certainly makes sense, sooner or later, the JVM and API changes will be finalized, marking the era of the Project Loom production readiness.

In today's post, we are going to cover some not so obvious quirks (by-products of the Project Loom implementation) you should be aware of (or may run into) while switching to JDK-19 in the green-field or, more importantly, brown-field projects. Those may manifest even if you are not planning to use Project Loom just yet.

Let us kick it off with API changes. The code snippet below uses old fashioned java.lang.Thread class to spawn some work aside. The computation uses the instance of the Builder inner class, the implementation of the Builder::build() method is left off since it is not really important.

public class Starter {
    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread() {
            public void run() {
                final Builder builder = new Builder();
                builder.build();
            }
        };
        thread.start();
        thread.join();
    }

    private static class Builder {
        public void build() {
            // implementation details
        }
    }
}

The code compiles and runs just fine on any modern JDK, predating JDK-19. On JDK-19 however, it fails to compile, with somewhat cryptic error.

Unresolved compilation problems: 
	Cannot instantiate the type Thread.Builder
	The method build() is undefined for the type Thread.Builder

The rare example of how existing code may clash with API changes: as part of the Project Loom, the java.lang.Thread got a new public sealed interface Builder, which is being rightly picked by the compiler (instead of our Builder class) inside Thread's the subclass. The fix is easy (but may not look pretty), just use the qualified class name:

public class Starter {
    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread() {
            public void run() {
                final Starter.Builder builder = new Starter.Builder();
                builder.build();
            }
        };
        thread.start();
        thread.join();
    }

    private static class Builder {
        public void build() {
            // implementation details
        }
    }
}

Please notice that nonetheless JDK's preview features were not enabled, the preview APIs are still visible and taken into the consideration by the compiler. The issue has been reported (JDK-8287968) and the possible incompatibilities have been documented (JDK-8288416).

The next quirk we are going to look at is also related to java.lang.Thread but this time we would be using thread pools (executors) from the standard library. Let us assume we need an executor instance which tracks the moment when the new thread is started. One of the options to accomplish that is to use custom java.util.concurrent.ThreadFactory and override Thread::start() method.

public class Starter {
    public static void main(String[] args) throws Exception {
        final ExecutorService executor = Executors.newSingleThreadExecutor(new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
                return new Thread(r) {
                    @Override
                    public void start() {
                        System.out.println("Thread has started!");
                        super.start();
                    }
                };
            }
        });
        
        executor.submit(() -> {}).get(1, TimeUnit.SECONDS);
        executor.shutdown();
    }
}

On JDKs prior to JDK-19, the expected message will be printed out in the console.

Thread has started!

But not in JDK-19: in scope of the Project Loom implementation, the thread pools and executors (notably ForkJoinPool and ThreadPoolExecutor) do not call Thread::start() method anymore. It does not matter if the preview features are enabled or not, and sadly, there is no workaround to simulate the desired behavior (the alternative Thread::start(ThreadContainer) replacement is not accessible). The issue has been reported and is still open as of today (JDK-8292027).

Great, so far we have seen some quirks caused by Project Loom irrespective of the fact it is used or not. Moving on, let us quickly summarize the constraints you may run into when using Project Loom (by enabling JDKs preview features) and virtual threads.

• be aware of the limitations using synchronized blocks or methods in scope of virtual threads
• be aware of the limitations using native methods or foreign functions in scope of virtual threads
• be aware of the limitations some APIs (like file system) in the JDK have when called in scope to virtual threads

Two JEPs, the JEP-425: Virtual Threads (Preview) and JEP-436: Virtual Threads (Second Preview) offer quite a comprehensive overview with respect to the virtual thread implementation and limitations in JDK-19 and upcoming JDK-20, worth of your time reading them. Another good source I would recommend is Coming to Java 19: Virtual threads and platform threads published by Java Magazine last May.

It is fair to say that Project Loom is evolving really fast, and this is the kind of the feature JVM really screamed for. Yes, it has some limitations now, but there are high chances that in the future most of them will be lifted or worked through.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

JDK 19: revolution is looming!

The JDK-19 landed last month and may look like yet another routine release except it is not: Project Loom has finally delivered first bits! Alhough still in half-incubation / half-preview, it is a really big deal to the future of OpenJDK platform. Interestingly enough, a vast majority of the JDK-19 JEPs are either preview or incubating features. So, what JDK-19 has to offer?

• JEP-425: Virtual Threads (Preview): introduces virtual threads to the Java Platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.

• JEP-428: Structured Concurrency (Incubator): simplifies multithreaded programming by introducing an API for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.

• JEP-405: Record Patterns (Preview): enhances the Java programming language with record patterns to deconstruct record values. Record patterns and type patterns can be nested to enable a powerful, declarative, and composable form of data navigation and processing.

• JEP-422: Linux/RISC-V Port: ports the JDK to RISC-V hardware.

• JEP-424: Foreign Function & Memory API (Preview): introduces an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. The JEP comes with a whole new java.lang.foreign package.

• JEP-426: Vector API (Fourth Incubator): introduces an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.

• JEP-427: Pattern Matching for switch (Third Preview): enhances the Java programming language with pattern matching for switch expressions and statements. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely.

• JDK-8283620: New System Properties for `System.out` and `System.err`: two new system properties, stdout.encoding and stderr.encoding, have been introduced. The value of these system properties is the encoding used by the System.out and System.err streams respectively (the default values of these system properties depend on the platform and fallback to the native.encoding property when the console streams are not available).

• JDK-8212136: Remove finalizer implementation in SSLSocketImpl: the underlying native resource releases are now done by the Socket implementation (the TLS close_notify messages will no longer be emitted if SSLSocket is not explicitly closed).

• JDK-8255495: Support CDS Archived Heap for uncompressed oops: adds support for uncompressed oops for CDS archived heap (for now, only G1 GC is supported, ZGC as a future target).

• JDK-8261455: Automatically generate the CDS archive if necessary: allows the CDS archive to be automatically generated if necessary (e.g., if the specified archive doesn't exist, or if it's out of date because the JDK version was updated).

      java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.jsa -cp app.jar AppMain
      

  In the previous JDKs, the CDS archive must be explicitly created before usage (with -Xshare:dump or -XX:ArchiveClassesAtExit).

• JDK-8278067: Make HttpURLConnection default keep alive timeout configurable: two new system properties have been added, http.keepAlive.time.server and http.keepAlive.time.proxy, which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time (by means of Keep-Alive header).

• JDK-8268081: Update Unicode Data Files to 14.0.0: introduces support of the Unicode Standard version 14.0.

• JDK-8281181: Do not use CPU Shares to compute active processor count: addresses an incorrect interpretation of the Linux cgroups parameter cpu.shares which might cause the JVM inside a container to use fewer CPUs than available.

• JDK-8274788: Support archived heap objects in ParallelGC: improves startup time since the module graph could be loaded from the archive.

• JDK-8280396: G1: Full gc mark stack draining should prefer to make work available to other threads and JDK-8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads: allow other threads to steal and distribute work.

• JDK-8176706: Additional Date-Time Formats: introduces additional date/time formats in the java.time.format.DateTimeFormatter and java.time.format.DateTimeFormatterBuilder classes. The new methods have been added to support that:

• To java.time.format.DateTimeFormatter:

  • static java.time.format.DateTimeFormatter ofLocalizedPattern(java.lang.String requestedTemplate)

• To java.time.format.DateTimeFormatterBuilder:

  • java.time.format.DateTimeFormatterBuilder appendLocalized(java.lang.String requestedTemplate)

  • static java.lang.String getLocalizedDateTimePattern(java.lang.String requestedTemplate, java.time.chrono.Chronology chrono, java.util.Locale locale)

• JDK-8285660: New System Property to Disable Windows Alternate Data Stream Support in java.io.File: a new system property jdk.io.File.enableADS has been added to control the access to NTFS Alternate Data Streams (ADS) on Windows (which is enabled by default).

• JDK-8280357: User's Home Directory set to $HOME if Invalid: on Linux and macOS, the system property user.home is set to the home directory provided by the operating system but if the directory name provided is empty or only a single character, the value of the environment variable HOME is going to be used instead.

• JDK-4511638: Double.toString(double) and Float.toString(float) may Return Slightly Different Results: the specification of these methods has been tightened comparing to earlier releases and the new JDK-19 implementation fully adheres to it. As a consequence, some returned strings are now shorter than when using earlier releases, and for inputs at the extremes of the subnormal ranges near zero, might look differently.

• JDK-8186958: New Methods to Create Preallocated HashMaps and HashSets: introduces new static factory methods to allow creation of HashMap and related instances that are preallocated to accommodate an expected number of mappings or elements.

  • Class java.util.WeakHashMap<K, V>

    • static <K, V> java.util.WeakHashMap<K, V> newWeakHashMap(int numElements)

  • Class java.util.HashMap<K, V>

    • static <K, V> java.util.HashMap<K, V> newHashMap(int numElements)

  • Class java.util.HashSet<E>

    • static <E> java.util.HashSet<E> newHashSet(int numElements)

  • Class java.util.LinkedHashMap<K, V>

    • static <K, V> java.util.LinkedHashMap<K, V> newLinkedHashMap(int numElements)

  • Class java.util.LinkedHashSet<E>

    • static <E> java.util.LinkedHashSet<E> newLinkedHashSet(int numElements)

• JDK-8274148: JShell Highlights Deprecated Elements, Variables, and Keywords: JShell now marks deprecated elements and highlights variables and keywords in the console.

• JDK-8271585: JFR: Scrub recording data: adds programmatic and command-line support to scrub a recording file (to scrub a recording file means to remove sensitive or uninteresting data to reduce the file size).

  jfr scrub [filters] [recording-file] [output-file]

  Please check out this short but insightful JFR Scrub - Sip of Java blog post to learn more about this JFR new command.

• From the standard library point of view, a large chunk of changes went into the classes under java.util.concurrent package so let us start from those:

• The java.util.concurrent.Future<T> (and its implementations like java.util.concurrent.CompletableFuture<T>, java.util.concurrent.FutureTask<T>, java.util.concurrent.ForkJoinTask<T>) got three new methods and one enumeration:

  • java.lang.Throwable exceptionNow()

  • T resultNow()

  • java.util.concurrent.Future$State state()

  • enum java.util.concurrent.Future$State

• The java.util.concurrent.ExecutorService now implements java.lang.AutoCloseable interface

• The java.util.concurrent.ForkJoinPool also implements java.lang.AutoCloseable interface and has two more methods:

  • <T> java.util.concurrent.ForkJoinTask<T> lazySubmit(java.util.concurrent.ForkJoinTask<T> task)

  • int setParallelism(int size)

• The java.util.concurrent.ForkJoinTask<T> additionally was enriched with:

  • static java.util.concurrent.ForkJoinTask<T> adaptInterruptible(java.util.concurrent.Callable<? extends T> callable)

  • boolean quietlyJoin(long timeout, java.util.concurrent.TimeUnit unit)

  • boolean quietlyJoinUninterruptibly(long timeout, java.util.concurrent.TimeUnit unit)

• The java.util.concurrent.Executors factory became even more capable with preview APIs:

  • static java.util.concurrent.ExecutorService newThreadPerTaskExecutor(java.util.concurrent.ThreadFactory threadFactory)

  • static java.util.concurrent.ExecutorService newVirtualThreadPerTaskExecutor()

• The java.lang.Thread comes at the end with whole bunch of additions (some also in preview):

  • boolean isVirtual()

  • boolean join(java.time.Duration duration)

  • long threadId()

  • static java.lang.Thread$Builder$OfPlatform ofPlatform()

  • static java.lang.Thread$Builder$OfVirtual ofVirtual()

  • static void sleep(java.time.Duration duration)

  • static java.lang.Thread startVirtualThread(java.lang.Runnable task)

  • interface Thread.Builder.OfVirtual

  • interface Thread.Builder.OfPlatform

  • interface Thread.Builder

• The java.lang.Long has introduced a new methods:

  • static long compress(long i, long mask)

  • static long expand(long i, long mask)

• Similarly, the java.lang.Integer has introduced this pair of methods:

  • static int compress(int i, int mask)

  • static int expand(int i, int mask)

• The class java.math.BigInteger got parallel multiplication support:

  • java.math.BigInteger parallelMultiply(java.math.BigInteger val)

• The class java.util.Locale was added a number of factory methods:

  • static java.util.Locale of(java.lang.String language, java.lang.String country, java.lang.String variant)

  • static java.util.Locale of(java.lang.String language, java.lang.String country)

  • static java.util.Locale of(java.lang.String language)

• The quite useful java.util.Objects utility class was not forgotten:

  • static java.lang.String toIdentityString(java.lang.Object o)

• The new factory method made it to java.util.Random class:

  • static java.util.Random from(java.util.random.RandomGenerator generator)

• The interface java.time.chrono.Chronology was enriched with new method:

  • boolean isIsoBased()

• Minor but useful addition to java.text.DecimalFormatSymbols class:

  • Locale getLocale()

• And java.lang.invoke.MethodHandles wraps it up with tons of new preview APIs:

  • static java.lang.invoke.VarHandle collectCoordinates(java.lang.invoke.VarHandle target, int pos, java.lang.invoke.MethodHandle filter)

  • static java.lang.invoke.VarHandle dropCoordinates(java.lang.invoke.VarHandle target, int pos, java.lang.Class<?>... valueTypes)

  • static java.lang.invoke.VarHandle filterCoordinates(java.lang.invoke.VarHandle target, int pos, java.lang.invoke.MethodHandle... filters)

  • static java.lang.invoke.VarHandle filterValue(java.lang.invoke.VarHandle target, java.lang.invoke.MethodHandle filterToTarget, java.lang.invoke.MethodHandle filterFromTarget)

  • static java.lang.invoke.VarHandle insertCoordinates(java.lang.invoke.VarHandle target, int pos, java.lang.Object... values)

  • static java.lang.invoke.VarHandle memorySegmentViewVarHandle(java.lang.foreign.ValueLayout layout)

  • static java.lang.invoke.VarHandle permuteCoordinates(java.lang.invoke.VarHandle target, java.util.List<Class<?>> newCoordinates, int... reorder)

From the security perspective, a few notable changes to mention (but feel free to go over much more detailed overview in the JDK 19 Security Enhancements post by Sean Mullan):

• JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default: the MD5 and SHA-1 message digest algorithms have been disabled by default for HTTP Digest authentication, they can re-enabled on an opt-in basis by setting a new system property http.auth.digest.reEnabledAlgorithms.

• JDK-8280494: (D)TLS signature schemes: introduces new APIs to customize the signature schemes for individual TLS or DTLS connections, for fine control of the security properties. The javax.net.ssl.SSLParameters was extended in these regards with two new methods:

  • java.lang.String[] getSignatureSchemes()

  • void setSignatureSchemes(java.lang.String[] signatureSchemes)

• JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos: adds the support for TLS channel binding tokens for Negotiate/Kerberos authentication over HTTPS through HttpsURLConnection.

If you are one of the early adopters, please note that JDK-19 introduced a native memory usage regression very late in the release process so that the fix could not be integrated any more (JDK-8292654). The regression has already been addressed in JDK 19.0.1 and later.

With that, hope you are as excited as I am about JDK-19 release, the peaceful revolution is looming! And the JDK-20 early access builds are already there, looking very promising!

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Quick, somewhat naïve but still useful: benchmarking HTTP services from the command line

Quite often, while developing HTTP services, you may find yourself looking for a quick and easy way to throw some load at them. The tools like Gatling and JMeter are the golden standard in the open-source world, but developing meaningful load test suites in both of them may take some. It is very likely you are going to end up with one of these but during the development, using more approachable tooling gives the invaluable feedback much faster.

The command line HTTP load testing tools is what we are going to talk about. There are a lot of them, but we will focus on just a few: ab, vegeta, wrk, wrk2, and rewrk. And since HTTP/2 is getting more and more traction, the tools that support both will be highlighted and awarded with bonus points. The sample HTTP service we are going to run tests against is exposing only single GET /services/catalog endpoint over HTTP/1.1, HTTP/2 and HTTP/2 over clear text.

Let us kick off with ab, the Apache HTTP server benchmarking tool: one of the oldest HTTP load testing tools out there. It is available on most Linux distributions and supports only HTTP/1.x (in fact, it does not implement HTTP/1.x fully). The standard set of parameters like desired number of requests, concurrency and timeout is supported.

$> ab -n 1000 -c 10 -s 1 -k  http://localhost:19091/services/catalog

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
...
Completed 1000 requests
Finished 1000 requests

Server Software:
Server Hostname:        localhost
Server Port:            19091

Document Path:          /services/catalog
Document Length:        41 bytes

Concurrency Level:      10
Time taken for tests:   51.031 seconds
Complete requests:      1000
Failed requests:        0
Keep-Alive requests:    0
Total transferred:      146000 bytes
HTML transferred:       41000 bytes
Requests per second:    19.60 [#/sec] (mean)
Time per request:       510.310 [ms] (mean)
Time per request:       51.031 [ms] (mean, across all concurrent requests)
Transfer rate:          2.79 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       5
Processing:     3  498 289.3    497    1004
Waiting:        2  498 289.2    496    1003
Total:          3  499 289.3    497    1004

Percentage of the requests served within a certain time (ms)
  50%    497
  66%    645
  75%    744
  80%    803
  90%    914
  95%    955
  98%    979
  99%    994
 100%   1004 (longest request)

The report is pretty comprehensive but if your service is talking over HTTP/2 or is using HTTPS with self-signed certificates (not unusual in development), you are out of luck.

Let us move on to a bit more advanced tools, or to be precise - a family of tools, inspired by wrk: a modern HTTP benchmarking tool. There are no official binary releases of wrk available so you are better off building the bits from the sources yourself.

$> wrk -c 50 -d 10 -t 5 --latency --timeout 5s https://localhost:19093/services/catalog

Running 10s test @ https://localhost:19093/services/catalog
  5 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   490.83ms  295.99ms   1.04s    57.06%
    Req/Sec    20.79     11.78    60.00     81.29%
  Latency Distribution
     50%  474.64ms
     75%  747.03ms
     90%  903.44ms
     99%  999.52ms
  978 requests in 10.02s, 165.23KB read
Requests/sec:     97.62
Transfer/sec:     16.49KB

Capability-wise, it is very close to ab with slightly better HTTPS support. The report is as minimal as it could get, however the distinguishing feature of the wrk is the ability to use LuaJIT scripting to perform HTTP request generation. No HTTP/2 support though.

wrk2 is an improved version of wrk (and is based mostly on its codebase) that was modified to produce a constant throughput load and accurate latency details. Unsurprisingly, you have to build this one from the sources as well (and, the binary name is kept as wrk).

$> wrk -c 50 -d 10 -t 5 -L -R 100 --timeout 5s https://localhost:19093/services/catalog

Running 10s test @ https://localhost:19093/services/catalog
  5 threads and 50 connections
  Thread calibration: mean lat.: 821.804ms, rate sampling interval: 2693ms
  Thread calibration: mean lat.: 1077.276ms, rate sampling interval: 3698ms
  Thread calibration: mean lat.: 993.376ms, rate sampling interval: 3282ms
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   933.61ms  565.76ms   3.35s    70.42%
    Req/Sec       -nan      -nan   0.00      0.00%
  Latency Distribution (HdrHistogram - Recorded Latency)
 50.000%  865.79ms
 75.000%    1.22s
 90.000%    1.69s
 99.000%    2.61s
 99.900%    3.35s
 99.990%    3.35s
 99.999%    3.35s
100.000%    3.35s

  Detailed Percentile spectrum:
       Value   Percentile   TotalCount 1/(1-Percentile)

      28.143     0.000000            1         1.00
     278.015     0.100000           36         1.11
     426.751     0.200000           71         1.25
                       ....
    2969.599     0.996875          354       320.00
    3348.479     0.997266          355       365.71
    3348.479     1.000000          355          inf
#[Mean    =      933.606, StdDeviation   =      565.759]
#[Max     =     3346.432, Total count    =          355]
#[Buckets =           27, SubBuckets     =         2048]
----------------------------------------------------------
  893 requests in 10.05s, 150.87KB read
Requests/sec:     88.85
Transfer/sec:     15.01KB

Besides these noticeable enhancements, the feature set of wrk2 is largely matching the wrk's one, so HTTP/2 is out of the picture. But do not give up just yet, we are not done.

The most recent addition to wrk's family is rewrk, a more modern HTTP framework benchmark utility, which could be thought of as wrk rewritten in beloved Rust with HTTP/2 support backed in.

$> rewrk -c 50 -d 10s -t 5 --http2 --pct --host https://localhost:19093/services/catalog

Beginning round 1...
Benchmarking 50 connections @ https://localhost:19093/services/catalog for 10 second(s)
  Latencies:
    Avg      Stdev    Min      Max
    494.62ms  281.78ms  5.56ms   1038.28ms
  Requests:
    Total:   972   Req/Sec:  97.26
  Transfer:
    Total: 192.20 KB Transfer Rate: 19.23 KB/Sec
+ --------------- + --------------- +
|   Percentile    |   Avg Latency   |
+ --------------- + --------------- +
|      99.9%      |    1038.28ms    |
|       99%       |    1006.26ms    |
|       95%       |    975.33ms     |
|       90%       |    942.94ms     |
|       75%       |    859.73ms     |
|       50%       |    737.45ms     |
+ --------------- + --------------- +

As you may have noticed, the report is very similar to the one produced by wrk. In my opinion, this is a tool which has a perfect balance of features, simplicity and insights, at least while you are in the middle of development.

The last one we are going to look at is vegeta, the HTTP load testing tool and library, written in Go. It supports not only HTTP/2, but HTTP/2 over clear text and has powerful reporting built-in. It heavily uses pipes for composing different steps together, for example:

$> echo "GET https://localhost:19093/services/catalog" | 
   vegeta attack -http2 -timeout 5s -workers 10 -insecure -duration 10s | 
   vegeta report

Requests      [total, rate, throughput]         500, 50.10, 45.96
Duration      [total, attack, wait]             10.88s, 9.98s, 899.836ms
Latencies     [min, mean, 50, 90, 95, 99, max]  14.244ms, 529.886ms, 537.689ms, 918.294ms, 962.448ms, 1.007s, 1.068s
Bytes In      [total, mean]                     20500, 41.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:500
Error Set:

You could also ask for histograms (with customizable reporting buckets), not to mention beautiful plots with plot command:

$> echo "GET http://localhost:19092/services/catalog" | 
   vegeta attack -h2c -timeout 5s -workers 10 -insecure -duration 10s | 
   vegeta report  -type="hist[0,200ms,400ms,600ms,800ms]"

Bucket           #    %       Histogram
[0s,     200ms]  86   17.20%  ############
[200ms,  400ms]  102  20.40%  ###############
[400ms,  600ms]  98   19.60%  ##############
[600ms,  800ms]  113  22.60%  ################
[800ms,  +Inf]   101  20.20%  ###############

Out of all above, vegeta is clearly the most powerful tool in terms of capabilities and reporting. It has all the chances to become the one-stop HTTP benchmarking harness even for production.

So we walked through a good number of tools, which one is yours? My advice would be: for HTTP/1.x, use ab; for basic HTTP/2 look at rewrk; and if none of these fit, turn to vegeta. Once your demands and sophistication of the load tests grow, consider Gatling or JMeter.

With that, Happy HTTP Load Testing!

The lost art of learning ... (a new programming language)

I remember the time, 20 years ago, when as a junior software developer I was driven by constant, non-stoppable desire to learn new things: new features, techniques, frameworks, architectures, styles, practices, ... and surely, new programming languages. This curiosity, hunger to learn, drove me to consume as many books as possible and to hunt around the clock for the scanty online publications available at that time.

Year after year, the accumulated knowledge backed by invaluable experience led me to settle on proven and battle-tested (in production) choices, which have worked, work these days and I am sure will work in the future. For me, the foundation was set in Java (later Scala as well) and JVM platform in general. This is where my expertise lays in, but don't get me wrong, I still try to read a lot, balancing on the edge between books and enormous amount of the blog posts, articles, talks and podcast. How many programming languages I was able to master for the last, let say, 10 years? If we count the JVM ecosystem only, Scala and Groovy would make the list, but otherwise - none, zero, 0. The pace of learning on this front has slowed for me, significantly ...

Why is that? Did I get burned out? Nope (thanks God). Fed up by development? Nope, hopefully never. Opionated? Yes, certainly. Older? Definitely. Less curious? Not really. To be fair, there are so many things going on in the JVM ecosystem, so many projects are being developed by the community, it has become increasingly difficult to find the time for something else! And frankly, why bother if you could do Java for the next 20 years without any fear of it disappearing or becoming irrelevant.

JVM is amazing platform but its fundamental principles heavily impact certain design aspects of any programming language built on top of it. It is good and bad (everything is a trade-off), but with the time, you as a developer get used to it, questioning if anything else makes sense. As many others, I ended up in the bubble which has to be blown up. How? I decided to learn Rust, and go way beyond the basics.

But no worries, I do not intend to sell you Rust but rather share an alarming discovery: the lost art of learning a new programming language. It all started as usual, crunching through the blogs, people's and companies' experiences and finally getting the book, Programming Rust: Fast, Safe Systems Development (really good one but the official The Rust Programming Language is equally awesome). A few months (!) later, I was done reading, feeling ready for delivering cool, production-ready Rust applications, or so I thought ... The truth - I was far, very far from it ... and those are the things I did wrong.

• Rust is concise (at least, to my taste), modern and powerful, but it is not a simple language. If some language aspects are not clear, do not skip over but try to understand them. If book is not doing sufficiently good job at it, look around till you get them, otherwise you risk to miss even more. I did not do that (overly confident that nothing could be harder than learning functional Scala) and at some point I was somewhat lost.

• In the same vein, Rust has unique perspective on many things, including concurrency and memory management, and investing the time to understand what those are is a must (the Java/JVM background is not very helpful here). Essentially, you have to "unlearn" in order to grasp certain new concepts, this is not easy and confuses the brain.

• Stay very focused and methodical, try to read at least few pages **every day**. Yes, we are all super busy, always distracted, have families and started to travel again, ... yada yada yada. Also, Programming Rust: Fast, Safe Systems Development is not a slim book: ~800 pages! Irregular, long breaks in reading were killing my progress.

• Practice, practice and practice. If you have some pet projects in mind, this is great, if not - just come up with anything ad-hoc but try to use the things you have just read about. Learning the "theory" is great, but mastering the programming language is all about using it every day to solve problems. I screwed there epically by following "bed time story" style ...

• Learn the coding practices and patterns by looking into the language's ecosystem, in this regard a curated list of Rust code and resources is super useful.

• Subscribe to newsletters to stay up to date and be aware what is going on in the core development and in the community. In case of Rust, the This Week in Rust turned out to be invaluable.

• Watch talks and presentations, luckily most of the conferences do publish all their videos online these days. I stumbled upon the official Rust YouTube channel and since then follow it closely.

Learning new programming language is rewarding experience, in particular when it happens to be Rust, a most beloved programming language for the last six years. But not only because of that, Rust is perfect fit for a system programming, something Java/JVM is inherently not suited very well (yes, it is better now with JEP 330: Launch Single-File Source-Code Programs, jbang and GraalVM native images but still far from being perfect for a task). From the other side, it is quite challenging when the programming language you are learning is not part of your day-to-day job.

As of this moment, I am not sure if Rust ever becomes my primary programming language but one thing I do know: I think every passionate software developer should strive to learn at least one new programming language every 1-2 years (we have so many good ones). It is amazing mental exercice and I used to follow this advice back in the days but lost the sight of it along the journey. I really should have not.

Happy learning and peace to everyone!

The show must go on: JDK-18 is here!

It feels like JDK-17 release just landed not so long ago, but there is a new one already out: please welcome JDK-18! Although it is not an LTS release, there are quite a few interesting features to talk about (the preview and incubator ones are not included).

• JEP-400: UTF-8 by Default: specifies UTF-8 as the default charset of the standard Java APIs. With this change, APIs that depend upon the default charset will behave consistently across all implementations, operating systems, locales, and configurations. In JDK-17 and earlier, the default charset is determined when the Java runtime starts and this behavior could be restored in JDK-18 using file.encoding system property by setting it to "COMPAT": -Dfile.encoding=COMPAT (the other supported value of this property is "UTF-8").

• JEP-416: Reimplement Core Reflection with Method Handles: reimplements java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs. To mitigate the compatibility risks, there is possibility to enable the old implementation via -Djdk.reflect.useDirectMethodHandle=false system property.

• JEP-418: Internet-Address Resolution SPI: defines a service-provider interface (SPI) for host name and address resolution, so that java.net.InetAddress can make use of resolvers other than the platform's built-in resolver. The new classes java.net.spi.InetAddressResolver and java.net.spi.InetAddressResolverProvider have been added into the standard library.

• JEP-421: Deprecate Finalization for Removal: deprecates finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled (via the new command-line option --finalization=disabled) to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be removed. Maintainers of libraries and applications that rely upon finalization should consider migrating to other resource management techniques such as the try-with-resources statement and cleaners.

• JEP-408: Simple Web Server: provides a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts. The following (new!) command line tool starts the Simple Web Server:

    $ jwebserver
      

  Alternatively, the components of the Simple Web Server (i.e., server, handler, and filter) could be accessed through the API and integrated into existing applications, if needed. The following new packages contain Simple Web Server SPI and implementation:

  • com.sun.net.httpserver
  • com.sun.net.httpserver.spi

  The quick example of the Simple Web Server API in action is below:

          var handler = new HttpHandler() {
              public void handle(HttpExchange exchange) throws IOException {
                  final String response = "OK";
                  exchange.sendResponseHeaders(200, response.length());
                  try (OutputStream os = exchange.getResponseBody()) {
                      os.write(response.getBytes());
                  }
              }
          };
  
          final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
          server.createContext("/", handler);
          server.start();
      

• JEP-413: Code Snippets in Java API Documentation: introduces an @snippet tag for JavaDoc's Standard Doclet, to simplify the inclusion of example source code in API documentation. This is probably one of the most interesting features of the JDK-18, let us take a look at it more closely by illustrating the usage of the Simple Web Server APIs usage.

      /**
       * The following code snippet shows how to use {@code HttpServer}:
       * {@snippet :
       *  final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
       *  server.createContext("/", handler);
       *  server.start();
       *  }
       */
    

  In this case, the snippet is embedded however it could also be externalized, for example:

      /**
       * The following code snippet shows how to use {@code HttpServer}:
       * {@snippet file="SimpleWebServerStarter.java" region="server"}
       */
      

  And here is the relevant part of the SimpleWebServerStarter.java content:

          var handler = ...;
  
          // @start region="server"
          final HttpServer server = HttpServer.create(new InetSocketAddress(9091), 0);
          server.createContext("/", handler);
          server.start();
          // @end
      

  In my opinion, the code snippets should significantly improve the quality and usefulness of Java documentation, hopefully we are going to see them getting traction. If you want to dig deeper, Dustin Marx has published an excellent post on the subject with more details.

• JDK-8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation. With that, the respective replacement delivered by JEP-353 and JEP-373 becomes the only implementation available going forward.

• JDK-8256425: Obsolete Biased Locking: finally wraps up JEP-374 which was supposed to be delivered in JDK-15 but was postponed due to community feedback.

• Support for string deduplication, used to be available in G1 only, was finally rolled into other garbage collectors: SerialGC, ParallelGC and ZGC.

• JDK-8275056: Virtualize G1CardSet containers over heap region: allows arbitrary combinations of the card table size with any heap region size.

• C2 compiler was enhanced with JDK-8259609: C2: optimize long range checks in long counted loops, JDK-8276116: C2: optimize long range checks in int counted loops and JDK-8276162: C2: Optimise unsigned comparison pattern.

• Notably, C1 compiler got JDK-8274983: C1: optimizes the invocation of private interface methods and JDK-8265518: C1: Intrinsic support for Preconditions.checkIndex

• JDK-8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT: fixes quite annoying issue when native-image can not match the hash of the runtime-generated bytecode to the pre-defined classes.

• JDK-8189591: No way to locally suppress doclint warnings: it becomes now possible to use @SuppressWarnings annotation to suppress messages from DocLint about issues in documentation comments, when it is not possible or practical to fix the issues that were found.

• JDK-8266936: Add a finalization JFR event: introduces a new JDK Flight Recorder event, jdk.FinalizerStatistics, to help identify classes that still use finalizers (at runtime).

• JDK-8274335: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields: expand javac's -Xlint:serial from checking the declaration of serialVersionUID fields to checking the declarations of all serialization-related fields and methods.

• JDK-8277861: Terminally deprecate Thread.stop: terminally deprecates Thread.stop method so it can be degraded and removed in the future release.

• JDK-8133686: HttpURLConnection's getHeaderFields method returns field values in reverse order: the multiple header values for a given field-name are now returned in the order in which they were added.

• JDK-8251329: Files.walkFileTree walks infinitely if zip has dir named "." inside: the ZIP file system provider has been changed to reject existing ZIP files that contain entries with "." or "..".

• JDK-8231640: Canonical property storage: introduces a new system property, java.properties.date, to allow applications to control the default date comment written out by the java.util.Properties::store methods.

• The java.nio.charset.Charset class got a new method:

  • static Charset forName(String charsetName, Charset fallback)

• The java.time.Duration got some love as well:

  • boolean isPositive()

• A new method went into java.io.PrintStream class:

  • Charset charset()

• The java.io.FileInputStream got a specialized implementation of (JDK-8272297):

  • long transferTo(java.io.OutputStream) throws IOException (overridden)

• One new method found its way into javax.lang.model.element.ExecutableElement interface:

  • Element getEnclosingElement()

• And a few methods were added to javax.lang.model.util.Elements interface:

  • TypeElement getOutermostTypeElement(Element e)
  • JavaFileObject getFileObjectOf(Element e)

• A very useful additions to javax.lang.model.SourceVersion enumeration to support mappings to runtime version:

  • Runtime.Version runtimeVersion()
  • static SourceVersion valueOf(Runtime.Version rv)

• The annotation processing got some improvements in the scope of javax.annotation.processing.Messager interface:

  • void printError(CharSequence msg)
  • void printError(CharSequence msg, Element e)
  • void printWarning(CharSequence msg)
  • void printWarning(CharSequence msg, Element e)
  • void printNote(CharSequence msg)
  • void printNote(CharSequence msg, Element e)

• The largest set of changes went into java.lang.Math utility class:

  • static int ceilDiv(int x, int y)
  • static long ceilDiv(long x, int y)
  • static long ceilDiv(long x, long y)
  • static int ceilDivExact(int x, int y)
  • static long ceilDivExact(long x, long y)
  • static int ceilMod(int x, int y)
  • static int ceilMod(long x, int y)
  • static long ceilMod(long x, long y)
  • static int divideExact(int x, int y)
  • static long divideExact(long x, long y)
  • static int floorDivExact(int x, int y)
  • static long floorDivExact(long x, long y)
  • static long unsignedMultiplyHigh(long x, long y)

• And, similarly, to java.lang.StrictMath utility class:

  • static int ceilDiv(int x, int y)
  • static long ceilDiv(long x, int y)
  • static long ceilDiv(long x, long y)
  • static int ceilDivExact(int x, int y)
  • static long ceilDivExact(long x, long y)
  • static int ceilMod(int x, int y)
  • static int ceilMod(long x, int y)
  • static long ceilMod(long x, long y)
  • static int divideExact(int x, int y)
  • static long divideExact(long x, long y)
  • static int floorDivExact(int x, int y)
  • static long floorDivExact(long x, long y)
  • static long unsignedMultiplyHigh(long x, long y)

The JDK-18 comes in with a large number of the security enhancements, including further work on phasing out SecurityManager and its APIs:

• JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore

• JDK-8275252: Migrate cacerts from JKS to password-less PKCS12: by password-less, it means the certificates are not encrypted and it contains no MacData for integrity check.

• JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs

• JDK-8270380: Change the default value of the java.security.manager system property to disallow: quite an impactful change for the projects which still rely on SecurityManager.

• JDK-8269039: Disabled SHA-1 Signed JARs

• New methods added to Subject class as part of JDK-8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs:

  • static Subject current() (replacement for static Subject getSubject(AccessControlContext acc))
  • static <T> T callAs(Subject subject, Callable<T> action) throws CompletionException (replacement for static <T> T doAs(Subject subject, PrivilegedAction<T> action) and static <T> T doAs(Subject subject, PrivilegedExceptionAction<T> action) throws PrivilegedActionException)

• The KeyStore got one new method, in scope of JDK-8225181:

  • final Set<KeyStore.Entry.Attribute> getAttributes(String alias) throws KeyStoreException

• And KeyStoreSpi as well:

  • Set<KeyStore.Entry.Attribute> engineGetAttributes(String alias)

And while we are enjoying the perils of JDK-18, the early access builds of JDK-19 are already available. There are not much details of what is coming just yet, but may be Project Loom would finally make its appearance in some form or another? Who knows ...

Peace to everyone!