Follow Java and OpenJDK on Twitter.

Oracle is proud to announce the general availability of JDK 20. This release is the 11th Feature Release delivered on time through the six-month release cadence. This level of predictability allows developers to easily manage their adoption of innovation thanks to a steady stream of expected improvements.

Java’s ability to boost performance, stability, and security continues to make it the world’s most popular programming language.

JDK 20 is now available!

Oracle now offers JDK 20 for developers, end-users, and enterprises.

Oracle JDK 20 is not a long-term support (LTS) release, therefore it will receive updates only until it is superseded in six months by JDK 21

Oracle JDK 17 (released on September 14, 2021) is the most recent long-term support (LTS) under the release cadence announced in 2018. Oracle announced plans to shorten the time between LTS releases, from three years to two years, so JDK 21 (September 2023) is planned to be the next LTS.

Java 20, Together

As we did with previous releases, with Java 20 we celebrate the contributions of many individuals and organizations in the OpenJDK Community — we all build Java, together!

JDK 20 Fix Ratio

The rate of change over time in the JDK releases has remained largely constant for years, but under the six-month cadence the pace at which production-ready features and improvements are delivered has sharply increased.

Instead of making tens of thousands of fixes and delivering close to one hundred JEPs (JDK Enhancement Proposals) every few years, as we did with yesteryear Major Releases, enhancements are delivered in leaner Feature Releases on a more manageable, predictable, six-month schedule. The changes range from significant new features to small enhancements to routine maintenance, bug fixes, and documentation improvements. Each change is represented in a single commit for a single issue in the JDK Bug System.

Of the 21,604 JIRA issues marked as fixed in Java 11 through Java 20 at the time of their GA, 15,420 were completed by people working for Oracle while 6,184 were contributed by individual developers and developers working for other organizations. Going through the issues and collating the organization data from assignees results in the following chart of organizations sponsoring the development of contributions in Java:

In Java 20, of the 2,314 JIRA issues marked as fixed, 1,595 were completed by Oracle, while 719 were contributed by other members of the Java community. Oracle would like to thank the developers working for organizations including Alibaba, Amazon, ARM, Google, Huawei, IBM, Intel, ISCAS, Red Hat, SAP, and Tencent for their notable contributions. We are also thankful to see contributions from smaller organizations such as Bellsoft, and Loongson, as well as independent developers who collectively contributed 7% of the fixes in Java 20.

We are equally grateful to the many experienced developers who reviewed proposed changes, the early adopters who tried out early access builds and reported issues, and the dedicated professionals who provided feedback on the OpenJDK mailing lists.

The following individuals provided invaluable feedback on build quality, logged good quality bugs, or offered frequent updates:

• Rick Hillegas (Apache Derby)
• Uwe Schindler (Apache Lucene)
• Rafael Winterhalter (Byte Buddy)
• Yoann Rodière (Hibernate projects)
• Marc Hoffman (JaCoCo)
• Lukas Eder (JOOQ)
• Vladimir Sitnikov (AssertJ)

Additionally, through the OpenJDK Quality Outreach program we would like to thank the following FOSS projects and individuals who provided excellent feedback on testing Java 20 early access builds to help improve the quality of the release:

• Apache Tomcat & Apache Wicket (Martin Grigorov)
• Apache Zookeeper (Enrico Olivelli)
• MyBatis (Iwao Ave)
• RxJava (David Karnok)
• Spoon (Martin Wittlinger)

As a special mention, we’d like to thank Rick Hillegas and the Apache Derby team for their reliable and regular feedback during each JDK release’s Early Access test cycle for several years now.

New in Java 20

Along with thousands of performance, stability and security updates, Java 20 delivers dozens of new features and enhancements, seven of those enhancements are significant enough to warrant their own JDK Enhancement Proposals - JEPs, covering four preview features and three incubator features.

Some of the most important changes not requiring a JEP, are:

• (D)TLS Key Exchange Named Groups
• Add GarbageCollectorMXBean for Remark and Cleanup Pause Time in G1
• Provide ChaCha20 Intrinsics on x86_64 and aarch64 Platforms
• Unicode 15.0 Support
• Improved Control of G1 Concurrent Refinement Threads
• Support for CLDR Version 42
• New JFR Event: jdk.InitialSecurityProperty
• New JFR Event: jdk.SecurityProviderService
• Improved Preview API Page
• New jmod --compress Command Line Option
• Grapheme Support in BreakIterator
• Update Timezone Data to 2022c
• Auto-Generated IDs in JavaDoc Headings

Full details of these and many other new features can be found in the release notes.

JEP Preview Features are fully specified and fully implemented Language or VM Features of the Java SE Platform; and yet impermanent. They are made available in JDK Feature Releases to allow for developer feedback based on real-world uses, before them becoming permanent in a future release. This also affords tool vendors the opportunity to work towards supporting features before they are finalized into the Java SE Standard.

JEP Incubator modules allow putting non-final APIs and non-final tools in the hands of developers and users to gather feedback that will ultimately improve the quality of the Java platform.

The seven JEPs delivered with Java 20 are grouped into three categories mapping to key long-term Java technology projects.

Project Amber

JEP 432 – Record Patterns (2^nd Preview)

Improves developer productivity by extending pattern matching to express more sophisticated, composable data queries. This is done by enhancing 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 432 relates to:

• [JDK 19] JEP 405: Record Patterns (Preview)
• [JDK 20] JEP 433: Pattern Matching for switch (4^th Preview)

JEP 433 – Pattern Matching for switch (4^th Preview)

Improves developer productivity by enhancing the Java programming language with pattern matching for switch expressions and statements. This improvement 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.

JEP 433 relates to:

• [JDK 19] JEP 427: Pattern Matching for switch (3^rd Preview)
• [JDK 20] JEP 432: Record Patterns (2^nd Preview)

Project Panama

JEP 434 - Foreign Function & Memory API (2^nd Preview)

The Foreign Function & Memory API offers value in four unique ways:

• Ease of use — Replaces the Java Native Interface (JNI) with a superior, pure-Java development model.
• Performance — Provides performance that is comparable to, if not better than, existing APIs such as JNI and `sun.misc.Unsafe.
• Generality — Provides ways to operate on different kinds of foreign memory (e.g., native memory, persistent memory, and managed heap memory) and, over time, to accommodate other platforms (e.g., 32-bit x86) and foreign functions written in languages other than C (e.g., C++, Fortran).
• Safety — Allows programs to perform unsafe operations on foreign memory but warn users about such operations by default.

The Foreign Function & Memory API 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 434 relates to:

• [JDK 19] JEP 424: Foreign Function & Memory API (Preview)

JEP 438 - Vector API (5^th Incubator)

Improves performance achieving performance superior to equivalent scalar computations. This is done by Introducing 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. Vector APIs were incubated in JDK 16 through 19. JDK 20 incorporates feedback from users of those releases as well as performance improvements and implementation enhancements.

JEP 438 relates to:

• [JDK 19] JEP 426: Vector API (4^th Incubator)

Project Loom

Project Loom aims to drastically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications that make the best use of available hardware. Work on Project Loom started in late 2017 and has resulted in six JEPs since JDK 19.

JEP 436 - Virtual Threads (2^nd Preview)

Virtual Threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.

Virtual Threads is the first JEP as part of Project Loom. Project Loom upgrades the Java concurrency model to meet the needs of today’s high-scale server applications.

There are a lot of great things about Java’s threads. They offer a natural programming model, with readable, sequential code using control flow operators that users understand – loops, conditionals, exceptions. Users get great debugging and serviceability, and readable stack traces. And threads are natural units of scheduling for OSes. We want to retain these advantages.

The problem is that the implementation of threads by the OS is too heavyweight. It takes too long to start a thread for each connection, but worse, the number of threads the OS can support at any one time limits the number of concurrent transactions a server can handle — to well below the capacity of the hardware or the network — and so threads become a severe constraining factor on server throughput.

Many people assumed we would embrace the asynchronous programming style offered by so-called “reactive” frameworks. By not representing concurrent operations directly as threads, it does scale beyond the limits posed by the thread-per-request model, but at a huge cost – much more complicated code that is harder to write, harder to read, and much harder to debug or profile because the platform in all its layers and its tools, is built around threads. Reactive may be the best people can do with the current JVM, but our goal is to do better, which we can do by making threads lighter and more scalable, letting developers keep using the model and tooling they’ve been using successfully for years.

Developers today have three bad options: waste hardware through underutilization, waste programmer effort with worse programming models and observability, or switch away from Java. So, Project Loom offers developers a better option.

JEP 429 – Scoped Values (Incubator)

Scoped Values 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 and offers value in a number of ways including:

• Ease of use — Provides a programming model to share data both within a thread and with child threads, so as to simplify reasoning about data flow.
• Comprehensibility — Makes the lifetime of shared data visible from the syntactic structure of code.
• Robustness — Ensures that data shared by a caller can be retrieved only by legitimate callees.
• Performance — Treats shared data as immutable so as to allow sharing by a large number of threads, and to enable runtime optimizations.

JEP 437 - Structured Concurrency (2^nd Incubator)

Structured Concurrency simplifies multithreaded programming by introducing an API for structured concurrency. This is done by simplifying 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 437 relates to:

• [JDK 19] JEP 428: Structured Concurrency (Incubator)

Resources

Java continues to be the #1 programming language for today’s technology trends. As the on-time delivery of improvements with Java 20 demonstrates, through continued thoughtful planning and ecosystem involvement, the Java platform is well-positioned for modern development and growth in the cloud.

Continue staying current with news and updates by:

• Visiting Dev.java (Oracle’s dedicated portal to advance your Java knowledge and community participation).
• Visiting Inside.java (news and views by the Java Team at Oracle).
• Listening to the Inside.java podcasts (an audio show for Java Developers brought to you directly from the people that make Java at Oracle. Conversations will discuss the language, the JVM, OpenJDK, platform security, innovation projects like Loom and Panama, and everything in between).
• Watching Inside.java Newscasts (a video show extending the Inside.java podcast into a video format).
• Watching Java on YouTube (Oracle’s collection of relevant Java videos to help grow your Java expertise).
• Watching JEP Café (Oracle’s technical exploration into popular JDK Enhancement Proposals).
• Joining the OpenJDK mailing lists (the place to learn about the progress of your favorite OpenJDK projects).
• Following OpenJDK and Java (social streams offering updates and news on the continual evolution of Java).
• Reading Java Magazine; Oracle’s digital Java publication offering technical articles by developers for developers.