JDK-21: green threads are officially back!

The JDK-21 is there, bringing virtual threads (back) into JVM as a generally available feature (if you are old enough like myself, you might have remembered that in Java 2 releases prior to 1.3 the JVM used its own threads library, known as green threads, to implement threads in the Java platform). This is big, but what else is coming?

• JEP-431: Sequenced Collections: introduces new interfaces to represent collections with a defined encounter order. Each such collection has a well-defined first element, second element, and so forth, up to the last element. It also provides uniform APIs for accessing its first and last elements, and for processing its elements in reverse order.

  The following new interfaces have been introduced (and retrofitted into the existing collections type hierarchy), potentially a breaking change for some library implementors:

  • java.util.SequencedCollection
  • java.util.SequencedMap
  • java.util.SequencedSet

• JEP-439: Generational ZGC: improves application performance by extending the Z Garbage Collector (ZGC) to maintain separate generations for young and old objects. This will allow ZGC to collect young objects — which tend to die young — more frequently.

  By default, the -XX:+UseZGC command-line option selects non-generational ZGC, but to select the Generational ZGC, additional command line option -XX:+ZGenerational is required:

  $ java -XX:+UseZGC -XX:+ZGenerational ...
  

• JEP-440: Record Patterns: 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. This is certainly a huge step towards having a powerful, feature-rich pattern matching capabilities in the language:

      interface Host {}
      record TcpHost(String name, int port) implements Host {}
      record HttpHost(String scheme, String name, int port) implements Host {}
      

  The are several places the records could be deconstructed, instanceof check being one of those:

      final Host host = new HttpHost("https", "localhost", 8080);
      if (host instanceof HttpHost(var scheme, var name, var port)) {
          ... 
      } else if (host instanceof TcpHost(var name, var port)) {
          ...
      }
      

• JEP-441: Pattern Matching for switch: 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.

  Considering the example with the records deconstruction from above, we could use record patterns in switch expressions too:

          var hostname = switch(host) {
              case HttpHost(var scheme, var name, var port) -> name;
              case TcpHost(var name, var port) -> name;
              default -> throw new IllegalArgumentException("Unknown host");
          };
      

  But the switch patterns are much more powerful, with guards to pattern case labels, null labels, etc.

          final Object obj = ... ; 
          var o = switch (obj) {
              case null ->  ... ;
              case String s -> ... ;
              case String[] a when a.length == 0 -> ... ;
              case String[] a -> ... ;
              default ->  ... ;
          }
      

• JEP-444: Virtual Threads: 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. The virtual threads and executors could be used along the traditional ones, following the same familiar API:

      try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
          executor.submit(() -> {
                  ...
          });
      }  
      

  Some of the quirks of the virtual threads we have discussed previously here and here, but there is one more: you could use them in parallel streams, but should you? The answer is a bit complicated, so referring you to Virtual Threads and Parallel Streams article if you are looking for clarity.

  The JDK tooling (like jcmd and jfr) has been updated to include the information about virtual threads where applicable.

  The jcmd thread dump lists virtual threads that are blocked in network I/O operations and virtual threads that are created by the ExecutorService interface. It does not include object addresses, locks, JNI statistics, heap statistics, and other information that appears in traditional thread dumps (as per Viewing Virtual Threads in jcmd Thread Dumps).

  Java Flight Recorder (JFR) can emit these events related to virtual threads (as per Java Flight Recorder Events for Virtual Threads):

  • jdk.VirtualThreadStart and jdk.VirtualThreadEnd (disabled by default)
  • jdk.VirtualThreadPinned (enabled by default with a threshold of 20 ms)
  • jdk.VirtualThreadSubmitFailed (enabled by default)

  It is worth noting that Oracle has published a comprehesive guide on virtual threads as par of JDK-21 documentation update.

• JEP-449: Deprecate the Windows 32-bit x86 Port for Removal: deprecates the Windows 32-bit x86 port, with the intent to remove it in a future release.

• JEP-451: Prepare to Disallow the Dynamic Loading of Agents: issues warnings when agents are loaded dynamically into a running JVM. These warnings aim to prepare users for a future release which disallows the dynamic loading of agents by default in order to improve integrity by default. Serviceability tools that load agents at startup will not cause warnings to be issued in any release.

  Running with -XX:+EnableDynamicAgentLoading on the command line serves as an explicit "opt-in" that allows agent code to be loaded into a running VM and thus suppresses the warning. Running with -XX:-EnableDynamicAgentLoading disallows agent code from being loaded into a running VM and can be used to test possible future behavior.

  In addition, the system property jdk.instrument.traceUsage can be used to trace uses of the java.lang.instrument API. Running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true causes usages of the API to print a trace message and stack trace. This can be used to identify agents that are dynamically loaded instead of being started on the command line with -javaagent.

• JEP-452: Key Encapsulation Mechanism API: introduces an API for key encapsulation mechanisms (KEMs), an encryption technique for securing symmetric keys using public key cryptography. The new APIs are centered around javax.crypto.KEM and javax.crypto.KEMSpi abstractions.

• JEP-430: String Templates (Preview): enhances the Java programming language with string templates. String templates complement Java's existing string literals and text blocks by coupling literal text with embedded expressions and template processors to produce specialized results. This is a preview language feature and API.

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

• JEP-443: Unnamed Patterns and Variables (Preview): enhances the Java language with unnamed patterns, which match a record component without stating the component's name or type, and unnamed variables, which can be initialized but not used. Both are denoted by an underscore character, _. This is a preview language feature.

• JEP-445: Unnamed Classes and Instance Main Methods (Preview): evolves the Java language so that students can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of Java, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. This is a preview language feature.

• JEP-446: Scoped Values (Preview): introduces scoped values, values that may be safely and efficiently shared to methods without using method parameters. They are preferred to thread-local variables, especially when using large numbers of virtual threads. This is a preview language API.

  In effect, a scoped value is an implicit method parameter. It is "as if" every method in a sequence of calls has an additional, invisible, parameter. None of the methods declare this parameter and only the methods that have access to the scoped value object can access its value (the data). Scoped values make it possible to pass data securely from a caller to a faraway callee through a sequence of intermediate methods that do not declare a parameter for the data and have no access to the data.

• JEP-442: Foreign Function & Memory API (3rd 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. This is a preview language API.

• JEP-448: Vector API (6th 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.

Those JEPs are the themes of JDK-21 but what other features are coming? There are quite a few to unpack to be fair.

• JDK-8296344: Remove Dependency on G1 for Writing the CDS Archive Heap: in previous JDKs, the dumping of the CDS archive heap has complex interactions with G1, however in JDK-21 those have been removed. That also makes it possible to dump the archive heap with non-G1 collectors.

• JDK-8298048: Combine CDS Archive Heap into a Single Block: combines all objects in the CDS archive heap into a single, contiguous block.

• JDK-8296263: Uniform APIs for Using Archived Heap Regions: replaces two different mechanisms that existed for using archived heap regions stored in a CDS archive with unified one to be used for all GC policies.

• JDK-8298966: Deprecate JMX Subject Delegation and the method JMXConnector.getMBeanServerConnection(Subject) for removal: deprecates the Java Management Extension (JMX) Subject Delegation feature for removal in a future release. The feature is enabled by the method getMBeanServerConnection(javax.security.auth.Subject) of the JMXConnector class which will be deprecated for removal.

• JDK-8311073: Note if implicit annotation processing is being used: by default, the long-standing policy is that annotation processing is implicitly enabled. As that policy may change in the future, the users should get some notice they are relying on implicit processing.

• JDK-8303530: Redefine JAXP Configuration File: provides the way to specify the properties file to be used by JAXP factories during the initialization outside of the JDK by specifying jdk.xml.config.file system property.

• JDK-8306703: JFR: Summary views: provides means to visualize aggregated event data from the shell. There are 70 predefined views, such as hot-methods, gc-pauses, pinned-threads, allocation-by-site, gc, memory-leaks-by-class, and more. A list of available views can be found through using jcmd <pid> JFR.view or jfr view <recoding> commands, for example:

  jcmd <pid> JFR.view allocation-by-site
  jcmd <pid> JFR.view hot-methods
  jcmd <pid> JFR.view
  
  jcmd <pid> JFR.view maxage=1h maxsize=2000MB gc-pauses
  jcmd <pid> JFR.view cell-height=3 truncate=beginning width=80 system-processes
  
  jfr view --cell-height 2 FreeMemory <recoding>
  jfr view --verbose gc <recoding>
      

• JDK-8267140: Support closing the HttpClient by making it auto-closable: the HttpClient now implements AutoCloseable and has been enriched with following new methods:

  • void close()

  • void shutdown()

  • void shutdownNow()

  • boolean awaitTermination(Duration duration)

  • boolean isTerminated()

• JDK-8306560: Add TOOLING.jsh load file: adds TOOLING.jsh load file to have better and built-in access for tools shipping with the JDK and their command-line interface. This is truly a gem since it is now possible to run tools provided by the Java Development Kit (JDK) in a JShell session (see please Running JDK Tools within a JShell Session for background).

  $ jshell TOOLING   
  |  Welcome to JShell -- Version 21
  |  For an introduction type: /help intro
  
  jshell> interface Empty {}
  jshell> javap(Empty.class)
    

  The list of available tools could be fetched using tools() method.

  jshell> tools()
  jar
  javac
  javadoc
  javap
  jdeps
  jlink
  jmod
  jpackage
  

• JDK-8015831: Add lint check for calling overridable methods from a constructor: this one was certainly on my wish list for a long time, the javac may issue a warning (new lint warning category this-escape) when detects the calling of the overridable methods in constructors (please check OpenJDK 21 Compiler Warning on Constructor Calling Overridable Methods for more details and excellent examples).

• JDK-8307466: java.time.Instant calculation bug in until and between methods: fixes the implementation of java.time.Instant.until(Temporal endExclusive, TemporalUnit unit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.

• JDK-8027682: javac wrongly accepts semicolons in package and import decls: disallow extra semicolons between import statements, for example

  	import java.util.Map;;;;
  	import java.util.Set;
  

  will now generate a compiler error (but for backward compatibility, when compiling source versions prior to 21, a warning is generated instead of an error).

• JDK-8026369: javac potentially ambiguous overload warning needs an improved scheme: prior to JDK-21, the javac compiler was omitting some potentially ambiguous overload warnings enabled by the -Xlint:overloads option.

• JDK-8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity: as it says, the Thread.sleep(long millis, int nanos) is now able to perform sub-millisecond sleep.

• JDK-8302659: Modernize Windows native code for NetworkInterface: the change may impact the implementations that lookup of network interfaces by calling NetworkInterace.getByName(String name) method however the display name returned by NetworkInterface.getDisplayName() has not been changed.

• JDK-8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter: replaces java.util.Formatter algorithm to format double and float with a the one used by Double.toString(double d).

• JDK-8205129: Remove java.lang.Compiler: the java.lang.Compiler class was deprecated for removal long time ago and it has been removed in JDK-21.

• JDK-8297295: Remove ThreadGroup.allowThreadSuspension: the method ThreadGroup.allowThreadSuspension was deprecated for removal since JDK-14 and its time has come.

The JDK-21 changeset looks already impressive but ... we are not done yet, let us walk through the standard library changes.

• New interfaces java.lang.constant.ModuleDesc and java.lang.constant.PackageDesc for describing Module and Package constants respectively.

• The com.sun.management.ThreadMXBean interface got one new default method:

  • default long getTotalThreadAllocatedBytes()

• The class java.util.concurrent.DelayQueue overrides:

  • java.util.concurrent.Delayed remove()

• As part of JDK-8301226, the java.lang.Math got new static method family:

  • static double clamp(double value, double min, double max)

  • static float clamp(float value, float min, float max)

  • static int clamp(long value, int min, int max)

  • static long clamp(long value, long min, long max)

• Under the same JDK-8301226 issue, the java.lang.StrictMath has those new methods too:

  • static double clamp(double value, double min, double max)

  • static float clamp(float value, float min, float max)

  • static int clamp(long value, int min, int max)

  • static long clamp(long value, long min, long max)

• In scope of JDK-8302323, the rare addition of the new methods to java.lang.StringBuilder class has happened:

  • StringBuilder repeat(int codePoint, int count)

  • StringBuilder repeat(CharSequence cs, int count)

• And similarly, still under JDK-8302323, to java.lang.StringBuffer class:

  • StringBuffer repeat(int codePoint, int count)

  • StringBuffer repeat(CharSequence cs, int count)

• The java.util.Locale was also refreshed with:

  • static Stream<Locale> availableLocales()

  • static String caseFoldLanguageTag(String languageTag)

• The JDK-8302590 and JDK-8305486 bring improvements to java.lang.String class:

  • int indexOf(int ch, int beginIndex, int endIndex)

  • int indexOf(String str, int beginIndex, int endIndex)

  • String[] splitWithDelimiters(String regex, int limit)

• The JDK-8305486 also touched the java.util.regex.Pattern class:

  • String[] splitWithDelimiters(CharSequence input, int limit)

• Probably the most love in JDK-21 was directed to emojis, with JDK-8303018 adding new emoji properties to java.lang.Character:

  • static boolean isEmoji(int codePoint)

  • static boolean isEmojiComponent(int codePoint)

  • static boolean isEmojiModifier(int codePoint)

  • static boolean isEmojiModifierBase(int codePoint)

  • static boolean isEmojiPresentation(int codePoint)

  • static boolean isExtendedPictographic(int codePoint)

• The java.util.regex.Pattern got some of the emoji share as well in scope of JDK-8305107: one can match characters that have emoji-related properties with the new \p{IsXXX} constructs, for example:

  Pattern.compile("\\p{IsEmoji}").matcher("🉐").matches() 
  

From the security perspective, JDK-21 is pretty packed with enhancements. Some of them we have highlighted above but a few more deserve special mentions (if you need a comprehensive look, please check out JDK 21 Security Enhancements article):

• JDK-8298127: HSS/LMS Signature Verification: implements support for Leighton-Micali Signatures (LMS) as described in RFC-8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

• JDK-8288050: Add support of SHA-512/224 and SHA-512/256 to the PBKDF2 and PBES2 impls in SunJCE provider: the SunJCE provider is enhanced with additional PBES2 Cipher and Mac algorithms, such as those using SHA-512/224 and SHA-512/256 message digests.

• JDK-8301553: Support Password-Based Cryptography in SunPKCS11: supports an initial set of Password-Based Cryptography algorithms in the SunPKCS11 security provider.

• JDK-8305091: Change ChaCha20 cipher init behavior to match AES-GCM: allows ChaCha20 decrypt-mode Cipher objects to reuse the key and nonce, conforming to the same rules that AES-GCM does.

• JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts: delivers an enhanced syntax for properties related to certificate, CRL, and OCSP connect and read timeouts. The new system properties com.sun.security.ocsp.readtimeout, com.sun.security.cert.timeout and com.sun.security.cert.readtimeout have been introduced to control this behavior.

From all perspectives, JDK-21 looks like the release worth migrating to (it is supposed to be LTS), despite the fact there are unforeseen delays announced by some vendors.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Java's SecurityManager in the age of virtual threads

The JDK-21 is just around the corner, bringing the virtual threads (JEP 444: Virtual Threads) to the mainstream, at least this is the plan so far. For vast majority of the projects out there the virtual threads open up a huge number of opportunities but for some - add new headaches.

More specifically, let us talk about niche projects that still rely on SecurityManager. The SecurityManager has been deprecated for removal in JDK-17 (JEP 411: Deprecate the Security Manager for Removal) and disallowed in JDK-18 (JDK-8270380). Its usage is discouraged but it is still there and is used in production systems.

Since JDK-21 early builds are available to everyone (as of this moment, the latest build is 21-ea+28-2377), let us find out what is happening when SecurityManager meets virtual threads. The code snippet below would serve as an example of the application that installs the SecurityManager and tries to fetch, well, the content of JEP 444, for sake of doing network calls. In the first attempt, we are going to use standard thread pool (operating system threads).

public class Starter {
    public static void main(String[] args) throws Exception {
        System.setSecurityManager(new SecurityManager());
        try (var executor = Executors.newSingleThreadExecutor()) {
            var future = executor.submit(() -> fetch("https://openjdk.org/jeps/444"));
            System.out.println(future.get());
        }
    }

    private static String fetch(String url) throws MalformedURLException, IOException, URISyntaxException {
        try (var in = new URI(url).toURL().openStream()) {
            return new String(in.readAllBytes(), StandardCharsets.UTF_8);
        }
    }
}

If we run this example using just java (thanks to JEP 330: Launch Single-File Source-Code Programs), it is going to fail with the java.security.AccessControlException:

$ java -Djava.security.manager=allow src/main/java/com/example/Starter.java

...
Exception in thread "main" java.util.concurrent.ExecutionException: java.security.AccessControlException: access denied ("java.net.SocketPermission" "openjdk.org:443" "connect,resolve")
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at com.example.Starter.main(Starter.java:15)
        Suppressed: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThread")
                at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
                at java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
                at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
                at java.base/java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:764)
                at java.base/java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1394)
                at java.base/java.util.concurrent.Executors$DelegatedExecutorService.shutdown(Executors.java:759)
                at java.base/java.util.concurrent.Executors$AutoShutdownDelegatedExecutorService.shutdown(Executors.java:846)
                at java.base/java.util.concurrent.ExecutorService.close(ExecutorService.java:413)
                at com.example.Starter.main(Starter.java:13)
                at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
                at java.base/java.lang.reflect.Method.invoke(Method.java:580)
                at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:484)
                at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:208)
                at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:135)
Caused by: java.security.AccessControlException: access denied ("java.net.SocketPermission" "openjdk.org:443" "connect,resolve")
        at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
        at java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
        at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
        at java.base/java.lang.SecurityManager.checkConnect(SecurityManager.java:905)
        at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:619)
        at java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264)
        at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:377)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:193)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1237)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1123)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:179)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1675)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1599)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223)
        at java.base/java.net.URL.openStream(URL.java:1325)
        at com.example.Starter.fetch(Starter.java:24)
        at com.example.Starter.lambda$main$0(Starter.java:14)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1583)

That is kind of expected, we need to craft the policy to allow the connection over socket to openjdk.org host, the minimal one we need is below, stored in src/main/resources/security.policy:

grant { 
    permission java.lang.RuntimePermission "modifyThread";
    permission java.net.SocketPermission "openjdk.org:443", "connect,resolve";
};

Now, if we rerun this example with this policy, it should print out the content of the JEP into the console (in HTML format):

$ java -Djava.security.manager=allow  -Djava.security.policy=src/main/resources/security.policy src/main/java/com/example/Starter.java

...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
...

Awesome, so let just switch over to virtual threads! It should just work, right?

public class Starter {
    public static void main(String[] args) throws Exception {
        System.setSecurityManager(new SecurityManager());
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            var future = executor.submit(() -> fetch("https://openjdk.org/jeps/444"));
            System.out.println(future.get());
        }
    }

    private static String fetch(String url) throws MalformedURLException, IOException, URISyntaxException {
        try (var in = new URI(url).toURL().openStream()) {
            return new String(in.readAllBytes(), StandardCharsets.UTF_8);
        }
    }
}

Or should it?

$ java -Djava.security.manager=allow  -Djava.security.policy=src/main/resources/security.policy src/main/java/com/example/Starter.java

...
Exception in thread "main" java.util.concurrent.ExecutionException: java.security.AccessControlException: access denied ("java.net.SocketPermission" "openjdk.org:443" "connect,resolve")
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at com.example.Starter.main(Starter.java:15)
Caused by: java.security.AccessControlException: access denied ("java.net.SocketPermission" "openjdk.org:443" "connect,resolve")
        at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
        at java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
        at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
        at java.base/java.lang.SecurityManager.checkConnect(SecurityManager.java:905)
        at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:619)
        at java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264)
        at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:377)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:193)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1237)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1123)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:179)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1675)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1599)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223)
        at java.base/java.net.URL.openStream(URL.java:1325)
        at com.example.Starter.fetch(Starter.java:20)
        at com.example.Starter.lambda$main$0(Starter.java:14)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.lang.VirtualThread.run(VirtualThread.java:311)

If you are surprised, so was I. But we really shouldn't be if we read JEP 444: Virtual Threads carefully enough. It says clearly:

• Virtual threads have no permissions when running with a SecurityManager set.

Why is that? Back in the days, the rumors were being spread that Project Loom was one of the reasons to kick SecurityManager out, the two didn't play well together. True or not, here we are.

For better or worse, the SecurityManager has transitioned from being the source of annoying deprecation warnings to rather a serious obstacle on the route of adopting recent JDK features. The time of making hard decisions is approaching very fast.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

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.