Primitive Patterns Preview Withdrawn Instead of Returning in JDK 28

On November 11, Angelos Bimpoudis and Gavin Bierman announced on the amber-spec-experts list that the primitive types in patterns, instanceof and switch preview feature will be withdrawn rather than re-previewed in JDK 28. The feature had gone through several preview rounds. It let pattern matching and switch work with primitive types, and made instanceof checks against primitives "safe" by testing whether a conversion would lose information.

Inside Java Newscast #117 (November 14) explains the reason: the arrival of value classes through Project Valhalla (JEP 401) raises new questions about how numeric conversions should behave. The semantics primitive patterns defined for conversions such as int to byte would need to line up with value-class numerics, so the Amber team is pulling the feature back for redesign instead of locking in rules that might conflict.

In practice, code that uses --enable-preview to switch on primitive types will not compile on JDK 28. Since this was always a preview feature, production code should not depend on it, but experimental code and teaching material should be updated.

Read more — Inside Java

A Valhalla Ticker in One int: Value Classes Measured

In a November 9 Inside Java article, Per-Åke Minborg builds a value class Ticker that packs up to five characters from a 37-symbol alphabet (A–Z, 0–9 and a dot) into a single 30-bit int. The class implements CharSequence and Comparable, and comparison simply uses the order of the packed integers, a pattern that suits compact identifiers such as stock tickers or codes.

On an Apple M4 Pro with an internal OpenJDK 28 build, an array of the value class (ValueTicker[]) took 0.261 ns per element, compared with 0.385 ns for the equivalent identity class, a median 1.47x speedup. The gain comes from flattening: value objects are stored inline in the array instead of behind object references, which removes pointer chasing and improves cache locality.

The code is preview-only: compile with --enable-preview --release 28 and run with --enable-preview. The article confirms that value classes (JEP 401) are part of the JDK 28 preview feature set, so this is a good time to try Valhalla on data-heavy code.

Read more — Inside Java

Java Roundup: A2A Java SDK 1.5, Gradle 9.9, Quarkus 4.0 Beta3, TornadoVM 8.1

InfoQ's roundup for the week of November 2, published November 9, covers a busy week of ecosystem releases. JDK 28 Early Access Build 23 is out. The A2A Java SDK 1.5.0 adds an OpenTelemetry decorator for push notifications and filtering for JPA-backed task listings, continuing Java's support for the agent-to-agent protocol. Gradle 9.9.0 brings incremental Kotlin DSL compilation through the Kotlin Build Tools API, JUnit Platform test filters, and Problems API improvements.

Other notable releases:

  • Quarkus 4.0.0.Beta3: Valkey support in the Redis client and a new @CheckedTemplateParam annotation.
  • TornadoVM 8.1.0: kernels can read and write device allocations owned by other libraries in place. TornadoInsight 2.1.0 adds an experimental AI-assisted conversion of a Java method into a TornadoVM kernel.
  • Open Liberty 26.0.0.11: a configurable quiesce timeout and redirect-domain validation for form login.
  • EclipseStore 4.3.0: a refactored VectorIndex and a new VanillaJS storage viewer.
  • Micrometer Metrics 1.18.0-RC2 / Tracing 1.8.0-RC2: second release candidates of the next minor versions, including fractional updates for Atlas counters.

JReleaser also published its 2.0 roadmap: the minimum will be JDK 25 and Gradle 9, and macOS Intel artifacts will be dropped.

Read more — InfoQ

Java and the Next Generation of Programming Models: Panama Today, Babylon Tomorrow

In a Devoxx Belgium 2026 session published on Inside Java on November 8, Ana-Maria Mihalceanu describes how Java is preparing for AI workloads. The first part covers what works today: using the Foreign Function & Memory API and jextract to interact safely with native, non-JVM runtimes, such as inference engines, from Java without JNI.

The second part looks ahead to Project Babylon code reflection, which would let AI models be written as ordinary Java programs. Babylon could then analyze them and compile them for inference engines and hardware accelerators. Mihalceanu frames the path as FFM-based inference now and pure-Java, accelerator-ready models later, which lets Java teams build AI features today without betting on unreleased APIs.

Read more — Inside Java