Inside Java
News and views from members of the Java team at Oracle
News and views from members of the Java team at Oracle
Follow Java and OpenJDK on Twitter.
Oracle is proud to announce the general availability of JDK 21. This release is the 12th 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.
Oracle now offers JDK 21 for developers, end-users, and enterprises.
Oracle will offer long term support for Java 21 for at least eight years. This extended support period gives organizations flexibility to keep applications in production longer with minimal maintenance, and to eventually migrate on their own terms. Based on customer feedback and use in the Java ecosystem, Oracle has also announced that long term support for Java 11 has been extended through at least January 2032, providing at least eight more years of support and updates from Oracle.
As did with previous releases, Java 21 celebrates the contributions of many individuals and organizations in the OpenJDK Community — we all build Java, together!
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 24,196 JIRA issues marked as fixed in Java 11 through Java 21 at the time of their GA, 17,288 were completed by people working for Oracle while 6,908 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 21, of the 2,585 JIRA issues marked as fixed, 1,868 were completed by Oracle, while 717 were contributed by other members of the Java community. Oracle would like to thank the developers working for organizations including Amazon, ARM, Azul, Google, Huawei, IBM, Intel , ISCAS, Red Hat, Rivos, 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 8% of the fixes in Java 21.
Additionally, through the OpenJDK Quality Outreach program we would like to thank the following FOSS projects that provided excellent feedback on testing Java 21 early access builds to help improve the quality of the release:
Apache Commons
Apache ZooKeeper
AssertJ
BNYM Code Katas
Eclipse Collections
JUnit5
Karate
MyBatis
Along with thousands of performance, stability and security updates, Java 21 delivers dozens of new features and enhancements, 15 of those enhancements are significant enough to warrant their own JDK Enhancement Proposals - JEPs, covering six preview features and one incubator feature.
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 15 JEPs delivered with Java 21 are grouped into six categories mapping to key long-term Java technology projects and hardware support.
JEP Goals:
Simplifies the writing of Java programs by making it easy to express strings that include values computed at run time.
Enhances the readability of expressions that mix text and expressions, whether the text fits on a single source line (as with string literals) or spans several source lines (as with text blocks).
Improves the security of Java programs that compose strings from user-provided values and pass them to other systems (e.g., building queries for databases) by supporting validation and transformation of both the template and the values of its embedded expressions.
Retains flexibility by allowing Java libraries to define the formatting syntax used in string templates.
Simplifies the use of APIs that accept strings written in non-Java languages (e.g., SQL, XML, and JSON).
Enables the creation of non-string values computed from literal text and embedded expressions without having to transit through an intermediate string representation.
Value:
Following the goals of Project Amber, String Templates aims to make the Java programming language more readable, writable, and maintainable.
JEP Goals:
Enhances the Java programming language by extending pattern matching to de-structure instances of record classes, enabling more sophisticated data queries.
Add nested patterns, enabling more composable data queries.
Related to:
[JDK 19] JEP 405: Record Patterns (Preview)
[JDK 20] JEP 432: Record Patterns (2nd Preview)
Value:
Makes the Java programming language more productive by extending pattern matching to express more sophisticated, composable data queries.
JEP Goals:
Expands the expressiveness and applicability of switch expressions and statements by allowing patterns to appear in case labels.
Allows the historical null-hostility of switch to be relaxed when desired.
Increases the safety of switch statements by requiring that pattern switch statements cover all possible input values.
Ensures that all existing switch expressions and statements continue to compile with no changes and execute with identical semantics.
Related to:
[JDK 17] JEP 406: Pattern Matching for switch (Preview)
[JDK 18] JEP 420: Pattern Matching for switch (2nd Preview)
[JDK 19] JEP 427: Pattern Matching for switch (3rd Preview)
[JDK 20] JEP 433: Pattern Matching for switch (4th Preview)
Value:
Improves the productivity of the Java programming language by making it more semantic so that complex data-oriented queries can be expressed concisely and safely.
JEP Goals:
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, _.
Value:
Improves the readability of record patterns by eliding unnecessary nested patterns.
Improves the maintainability of all code by identifying variables that must be declared (e.g., in a catch clause) but will not be used.
JEP Goals:
Offers a smooth on-ramp to Java so that educators can introduce programming concepts in a gradual manner.
Helps students to write basic programs in a concise manner and grow their code gracefully as their skills grow.
Reduces the ceremony of writing simple programs such as scripts and command-line utilities.
Does not introduce a separate beginner's dialect of Java.
Does not introduce a separate beginners' toolchain; student programs should be compiled and run with the same tools that compile and run any Java program.
Value:
Evolves the Java language by reducing the boilerplate and ceremony so that students can write their first programs without needing to understand language features designed for large programs.
JEP Goals:
Enables server applications written in the simple thread-per-request style to scale with near-optimal hardware utilization.
Enables existing code that uses the java.lang.Thread API to adopt virtual threads with minimal change.
Enables easy troubleshooting, debugging, and profiling of virtual threads with existing JDK tools.
Relates to:
[JDK 20] JEP 436: Virtual Threads (2nd Preview)
[JDK 19] JEP 425: Virtual Threads (Preview)
Value:
Accelerates application development productivity such as apps targeted for cloud environments by introducing Virtual threads, which are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.
JEP Goals:
Enables the sharing of immutable data within and across threads.
Related to:
[JDK 20] JEP 429: Scoped Values (Incubator)
Value:
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 Goals:
Simplifies concurrent programming by introducing an API for structured concurrency.
Promotes a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays.
Improves the observability of concurrent code.
Related to:
[JDK 19] JEP 428: Structured Concurrency (Incubator)
[JDK 20] JEP 437: Structured Concurrency (2nd Incubator)
Value:
Simplifies concurrent programming by introducing an API for structured concurrency. which streamlines error handling and cancellation, improves reliability, and enhances observability.
JEP Goals:
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 API.
Related to:
[JDK 19] JEP 424: Foreign Function & Memory API (Preview)
[JDK 20] JEP 434: Foreign Function & Memory API (2nd Preview)
Value:
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.
JEP Goals:
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.
Included are the following notable changes:
Adds the exclusive or (xor) operation to vector masks.
Improves the performance of vector shuffles, especially when used to rearrange the elements of a vector and when converting between vectors.
Related to:
[JDK 16] JEP 338: Vector API (Incubator)
[JDK 17] JEP 414: Vector API (2nd Incubator)
[JDK 18] JEP 417: Vector API (3rd Incubator)
[JDK 19] JEP 426: Vector API (4th Incubator)
[JDK 20] JEP 438: Vector API (5th Incubator)
Value:
Offers a clear and concise API that is capable of clearly and concisely expressing a wide range of vector computations consisting of sequences of vector operations composed within loops and possibly with control flow
The API should be CPU architecture agnostic, enabling implementations on multiple architectures supporting vector instructions.
Offers a reliable runtime compilation and performance on x64 and AArch64 architectures.
Aligns with Project Valhalla.
JEP Goals:
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.
Provides uniform APIs for accessing its first and last elements, and for processing its elements in reverse order.
Value:
Improves developer productivity by offering a uniform set of operations that apply across a collection type that represents a sequence of elements with a defined encounter order.
JEP Goals:
Improves application performance by extending the Z Garbage Collector (ZGC) to maintain separate generations for young and old objects.
Value:
Applications running with Generational ZGC should enjoy:
Lower risks of allocations stalls.
Lower required heap memory overhead.
Lower garbage collection CPU overhead.
These benefits should come without significant throughput reduction compared to non-generational ZGC. The essential properties of non-generational ZGC should be preserved:
Pause times should not exceed 1 millisecond.
Heap sizes from a few hundred megabytes up to many terabytes should be supported.
Minimal manual configuration should be needed.
JEP Goals:
Introduce an API for key encapsulation mechanisms (KEMs), an encryption technique for securing symmetric keys using public key cryptography.
Value:
Enables applications to use KEM algorithms such as the RSA Key Encapsulation Mechanism (RSA-KEM), the Elliptic Curve Integrated Encryption Scheme (ECIES), and candidate KEM algorithms for the National Institute of Standards and Technology (NIST) Post-Quantum Cryptography standardization process.
Enables the use of KEMs in higher level protocols such as Transport Level Security (TLS) and in cryptographic schemes such as Hybrid Public Key Encryption (HPKE, RFC 9180).
Allows security providers to implement KEM algorithms in either Java code or native code.
Includes an implementation of the Diffie-Hellman KEM (DHKEM) defined in §4.1 of RFC 9180.
JEP Goals:
Deprecates the Windows 32-bit x86 port, with the intent to remove it in a future release.
Value:
Updates the build system to issue an error message when an attempt is made to configure a build for Windows 32-bit x86 (x86-32). The error message will be suppressible via a new configuration option.
Marks the port, and related port-specific features, as deprecated for removal in the relevant documentation.
JEP Goals:
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.
Value:
Prepares for a future release of the JDK that will, by default, disallow the loading of agents into a running JVM.
Reassesses the balance between serviceability, which involves ad-hoc changes to running code, and integrity, which assumes that running code is not arbitrarily changed.
Ensures that the majority of tools — which do not need to load agents dynamically — are unaffected.
Aligns the ability to load agents dynamically with other so-called "superpower" capabilities, such as deep reflection.
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 Java on YouTube (Oracle’s collection of relevant Java videos to help grow your Java expertise).
Watching Inside.java Newscasts (a video show covering recent developments in the OpenJDK community.)
Watching JEP Café (Oracle’s technical exploration into popular JDK Enhancement Proposals).
Watching Sip of Java (Oracle’s short form videos offering introductions into lesser known Java enhancements).
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).
