Key:

JDK-X  - https://bugs.openjdk.java.net/browse/JDK-X
CVE-XXXX-YYYY: https://cve.mitre.org/cgi-bin/cvename.cgi?name=XXXX-YYYY

New in release OpenJDK 21.0.0 (2023-09-XX):
===========================================
Major changes are listed below.  Some changes may have been backported
to earlier releases following their first appearance in OpenJDK 18
through to 21.

NEW FEATURES
============

Language Features
=================

Pattern Matching for switch
===========================
https://openjdk.org/jeps/406
https://openjdk.org/jeps/420
https://openjdk.org/jeps/427

Enhance the Java programming language with pattern matching for
`switch` expressions and statements, along with extensions to the
language of patterns. 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.

This was a preview feature (http://openjdk.java.net/jeps/12) in
OpenJDK 17 (JEP 406) and saw a second preview in OpenJDK 18 (JEP 420).
It reaches its third preview (JEP 427) in OpenJDK 19.

Record Patterns
===============
https://openjdk.org/jeps/405

Enhance 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 a preview feature (http://openjdk.java.net/jeps/12) introduced
in OpenJDK 19 (JEP 405)

Library Features
================

UTF-8 by Default
================
https://openjdk.org/jeps/400

Specify 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.

Reimplement Core Reflection with Method Handles
===============================================
https://openjdk.org/jeps/416

Reimplement 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.

Vector API
==========
https://openjdk.org/jeps/338
https://openjdk.org/jeps/414
https://openjdk.org/jeps/417
https://openjdk.org/jeps/426

Introduce an API to express vector computations that reliably compile
at runtime to optimal vector hardware instructions on supported CPU
architectures and thus achieve superior performance to equivalent
scalar computations.

This is an incubation feature (https://openjdk.java.net/jeps/11)
introduced in OpenJDK 16 (JEP 338). A second round of incubation took
place in OpenJDK 17 (JEP 414), OpenJDK 18 (JEP 417) saw a third and
OpenJDK 19 sees its fourth (JEP 426).

Internet-Address Resolution SPI
===============================
https://openjdk.org/jeps/418

Define 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.

Foreign Function & Memory API
=============================
https://openjdk.org/jeps/412
https://openjdk.org/jeps/419
https://openjdk.org/jeps/424

Introduce 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 API is now a preview feature (http://openjdk.java.net/jeps/12).
It was first introduced in incubation
(https://openjdk.java.net/jeps/11) in OpenJDK 17 (JEP 412), and is an
evolution of the Foreign Memory Access API (OpenJDK 14 through 16) and
Foreign Linker API (OpenJDK 16) (see release notes for
java-17-openjdk). OpenJDK 18 saw a second round of incubation (JEP
419) before its inclusion as a preview in OpenJDK 19 (JEP 424).

Virtual Threads
===============
https://openjdk.org/jeps/425

Introduce 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.

This is a preview feature (http://openjdk.java.net/jeps/12) introduced
in OpenJDK 19 (JEP 425)

Structured Concurrency
======================
https://openjdk.org/jeps/428

Simplify 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.

This is an incubation feature (https://openjdk.java.net/jeps/11)
introduced in OpenJDK 19 (JEP 428).

Tools
=====

Simple Web Server
=================
https://openjdk.org/jeps/408

Provide a command-line tool, `jwebserver`, 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.

Code Snippets in Java API Documentation
=======================================
https://openjdk.org/jeps/413

Introduce an @snippet tag for JavaDoc's Standard Doclet, to simplify
the inclusion of example source code in API documentation.

Ports
=====

Linux/RISC-V Port
=================
https://openjdk.org/jeps/422

RISC-V is a free and open-source RISC instruction set architecture
(ISA) designed originally at the University of California, Berkeley,
and now developed collaboratively under the sponsorship of RISC-V
International. It is already supported by a wide range of language
toolchains. With the increasing availability of RISC-V hardware, a
port of the JDK would be valuable.

DEPRECATIONS
============

Deprecate Finalization for Removal
==================================
https://openjdk.org/jeps/421

Deprecate finalization for removal in a future release. Finalization
remains enabled by default for now, but can be 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.
