← Back to all briefings
Developer 7 min read Published Updated Credibility 40/100

Developer Briefing — March 22, 2022

Java 18, released on March 22, 2022 under the six‑month feature‑release cadence, introduces nine JDK Enhancement Proposals (JEPs) and thousands of performance and stability improvements. The non‑LTS release standardizes UTF‑8 as the default encoding, ships a simple HTTP file server, re‑implements core reflection using method handles, adds a pluggable internet‑address resolution SPI, improves API documentation with code snippets, incubates the Vector API and foreign function & memory APIs, previews pattern matching for switch expressions and deprecates finalization. This briefing explains the new features, the short support window, and how developers and organizations can prepare for migration and adopt the release for testing and experimentation.

Zeph Tech Research Lead

Research lead, Zeph Tech

Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Executive summary. Java 18 is the ninth feature release in the six‑month cadence and became generally available on March 22 2022. It is not a long‑term support (LTS) version—Oracle will provide performance, stability and security updates for only six months before decommissioning【613239596868559†L19-L24】. That predictable release schedule allows organizations to absorb smaller sets of changes more frequently and encourages experimentation with new APIs before the next LTS (Java 21) arrives. This briefing summarizes the nine JDK Enhancement Proposals (JEPs) in this release and offers practical guidance for developers planning to adopt Java 18 for testing and early development.

Overview of the Java release cadence and licensing

Since 2018, Java has followed a six‑month feature‑release cycle, delivering smaller sets of features at regular intervals. Oracle emphasizes that this cadence makes adoption of innovation more manageable and predictable【613239596868559†L19-L24】. Java 18 is a non‑LTS release, unlike Java 17, meaning it will only receive updates for six months【613239596868559†L37-L48】. Oracle continues to offer JDK binaries under a no‑fee license for individual and commercial use; after Java 17 and subsequent LTS versions, the company reduced the time between LTS releases from three years to two years and will support each LTS for at least three years【613239596868559†L37-L48】. Consequently, the next LTS will be Java 21 in September 2023, so Java 18 serves as an interim platform for developers to explore new features.

Key enhancement proposals in Java 18

Java 18 implements nine JEPs covering core library improvements, tooling enhancements, preview and incubating features, and deprecations. These enhancements aim to improve predictability, portability, and developer experience across the JVM and standard library. Below we describe each JEP and its implications.

UTF‑8 by default (JEP 400)

One of the most visible changes is standardizing UTF‑8 as the default character set for Java APIs【613239596868559†L150-L155】. Prior to Java 18, the default charset varied by operating system; on US systems it was often Windows‑1252 or ISO‑8859‑1. JEP 400 eliminates this inconsistency by mandating UTF‑8 across the standard libraries. This makes applications more predictable and portable because developers can rely on the same default encoding for file and network I/O on any platform. The change affects APIs such as Files.readString, InputStreamReader and URLDecoder. Since many libraries already default to UTF‑8, most applications will benefit with minimal changes. However, developers should audit code that relies on platform encoding and explicitly specify a charset where necessary.

Simple Web Server (JEP 408)

JEP 408 introduces a simple HTTP file server that is built into the JDK. The new jwebserver tool and supporting API allow developers to serve static files from a directory with a single command【613239596868559†L159-L163】. The server is intended for prototyping, testing and educational use; it is not designed for production workloads. In addition to the command‑line tool, the com.sun.net.httpserver.SimpleFileServer class provides an easy‑to‑use API for embedding a file server in applications. The simple server reduces the friction of creating quick demos or hosting API documentation locally and encourages developers to experiment with HTTP features without pulling in third‑party dependencies.

Reimplement core reflection with method handles (JEP 416)

Reflection is a powerful feature of Java but has historically been implemented with complex native code that is difficult to maintain. JEP 416 reimplements the core reflection mechanism—java.lang.reflect—on top of method handles【613239596868559†L167-L170】. Method handles are a low‑level, type‑safe mechanism introduced in Java 7 for dynamic invocation. By using them internally, reflection benefits from a simpler implementation, better performance and improved maintenance. For developers, the API remains largely unchanged, but the underlying reimplementation lays groundwork for future language features and reduces the cost of evolving the JVM.

Internet‑Address Resolution SPI (JEP 418)

Traditionally, Java has used the operating system’s DNS resolver to translate host names to IP addresses, causing blocking calls and limited extensibility. JEP 418 introduces a Service Provider Interface (SPI) that allows applications to supply custom name resolvers【613239596868559†L172-L177】. Implementations of the java.net.spi.InetAddressResolverProvider can integrate DNS over HTTPS, DANE (DNS‑based Authentication of Named Entities) or other advanced resolution mechanisms. This improves the flexibility and testability of network‑oriented applications and paves the way for pluggable name services in Java.

Code snippets in API documentation (JEP 413)

The Javadoc tool now supports injecting and validating code snippets in API documentation【613239596868559†L181-L188】. JEP 413 enhances the @snippet tag so that example code is compiled, syntax‑highlighted and linked to declarations. This reduces documentation drift, improves readability and helps ensure that code examples remain valid across releases. Better tooling also encourages library maintainers to include runnable examples, enhancing adoption and comprehension of APIs.

Incubator and preview features

Three JEPs in Java 18 introduce incubator or preview APIs that will likely evolve before becoming permanent. JEP 417 adds a third incubator of the Vector API, providing a platform‑agnostic mechanism for expressing vector computations that can leverage SIMD instructions on modern CPUs【613239596868559†L195-L198】. JEP 419 brings a second incubator of the Foreign Function & Memory API, which simplifies calling native libraries and managing off‑heap memory【613239596868559†L200-L204】. Finally, JEP 420 delivers the second preview of pattern matching for switch expressions【613239596868559†L206-L211】, extending the pattern matching features introduced in earlier releases. Pattern matching for switch allows developers to match on type patterns and values within a single expression, reducing boilerplate code and improving safety. These incubating and preview features are disabled by default and must be enabled with compiler flags (e.g., --add-modules jdk.incubator.vector or --enable-preview). They provide an opportunity to experiment and give feedback on future language and runtime improvements.

Deprecation of finalization (JEP 421)

Finalization has long been considered problematic: it introduces unpredictability, hampers performance and complicates resource management. JEP 421 officially deprecates finalization for removal in a future release【613239596868559†L215-L218】. To aid migration, Java 18 adds a command‑line option --finalization=disabled that throws exceptions when a class overrides finalize(). Developers are encouraged to adopt try‑with‑resources or cleaners for deterministic resource cleanup and to monitor logs for finalizer usage. Deprecating finalization is a significant step toward simplifying the JVM and promoting modern idioms.

Implications for developers and organizations

As a non‑LTS release, Java 18 is best suited for early adoption, experimentation and testing of applications against new features. Organizations running production workloads should plan to migrate directly from Java 17 LTS to Java 21 LTS unless specific JEPs in Java 18 offer compelling benefits. However, adopting Java 18 in development environments can surface compatibility issues early and allow teams to provide feedback to the OpenJDK project. Key considerations include:

  • Encoding changes: Audit code that relies on the platform’s default charset and explicitly specify encodings where necessary. UTF‑8 by default reduces surprises but can expose latent assumptions.
  • HTTP and network utilities: Leverage the simple web server for documentation hosting or prototyping. Consider exploring the Internet‑Address Resolution SPI for custom DNS integrations.
  • Documentation quality: Use the enhanced @snippet tag to ensure example code in Javadoc remains correct and well‑formatted.
  • Native interop and performance: Experiment with the Vector API and Foreign Function & Memory API to prototype high‑performance or native‑dependent functionality. Provide feedback to help shape these APIs before they become stable.
  • Switch patterns and finalization: Try the preview of pattern matching for switch to simplify control flow. Begin removing or refactoring finalize() methods in preparation for their removal.

Zeph Tech analysis and recommendations

Java 18 reflects the maturity of the six‑month release cadence: incremental yet meaningful improvements, strong early feedback cycles and de‑risking of long‑term features through incubators. The uniform UTF‑8 default eliminates a longstanding source of bugs, while the simple web server and Internet‑Address SPI demonstrate the JDK’s move toward pragmatic developer tooling. Although most enterprises will wait for Java 21 LTS before upgrading production systems, using Java 18 in non‑production environments helps build muscle memory around the new features and fosters community input. We recommend:

  • Testing applications on Java 18 in development pipelines to evaluate compatibility and performance impacts.
  • Updating build and CI/CD scripts to specify explicit encodings and to take advantage of the simple web server for ad‑hoc documentation hosting.
  • Participating in the incubator and preview API feedback process to shape the future of the Java platform.
  • Mapping a migration path from Java 17 LTS to Java 21 LTS, with checkpoints at Java 18 and Java 19 to ensure readiness for upcoming features.

By understanding and experimenting with the enhancements in Java 18, organizations can better prepare for the next LTS release and ensure that applications remain secure, performant and maintainable.

Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Java
  • Java 18
  • JDK 18
  • Vector API
  • Foreign Function and Memory API
  • UTF-8 default
  • Simple Web Server
Back to curated briefings