Java's checked exceptions are both an integral part of the language and one of its most contested features. Whether their introduction was a mistake and whether they should all be turned unchecked are frequently discussed topics but since the former is not overly relevant and the latter unlikely, this conversation isn't moving Java forward. Instead, let's talk about specific issues with checked exceptions and what could be done about them - from (entirely speculative) language changes to (marginally realistic) JDK/library evolution to stylistic changes.

Lazily initializing fields in Java is error-prone and undermines constant-folding. JDK 26 comes with JEP 526, which previews LazyConstant, a type that lazily initializes a value through a given Supplier. It executes that supplier at most once successfully and then assigns the value to a field annotated with @Stable, which allows constant folding. This API is also a poster child for how OpenJDK develops and evolves features.

HTTP/3 is the next version of the internet's most important application layer protocol. But, somewhat surprisingly, it uses UDP (via the new QUIC protocol) instead of TCP/IP, which has implications for the number of initial round trips, HTTP version selection, and time to first byte, but also adoption and evolution. Java 26 supports HTTP/3 out of the box.

Nicolai Parlog talks to Daniel Fuchs and Daniel Jelinski, both Consulting Members of Technical Staff at Oracle and OpenJDK committers, about Java's HTTP client. They start by briefly retracing its introduction in Java 11 and its support for HTTP/2 before diving deeper into HTTP/3 to learn about the motivation, technical underpinnings like the QUIC protocol, and challenges for its adoption before discussing its integration into Java 26

Note: Sorry for the minor audio issues, thank you for your understanding.

This episode presents Project Amber lead Brian Goetz's recent email "Data Oriented Programming, Beyond Records", wherein he describes plans to improve Java's data handling capabilities by introducing carrier classes, a generalization of records. Like them, carrier classes describe their state through a component list that defines the type's external API: accessors, a constructor, and matching deconstructor - this allows carrier classes to participate in pattern matching and reconstruction. Unlike records, the implementation of this API remains the developer's task although component fields offer a shortcut for the common case where the API does map to a field. Carrier classes don't have to be final (and can hence participate in inheritance) and neither do their fields (so they can be mutable data carriers). The email also mentions carrier interfaces, allowing records to be abstract as well as a relaxation of deconstruction patterns that make them more amenable to evolution of the matched type. This episode also briefly touches on Gavin Bierman's mail to the Project Amber mailing list that announces pattern assignments and constant patterns.

In 2026, Java keeps evolving: Project Valhalla is gunning for merging its value types preview in the second half of this year; Babylon wants to incubate code reflection; Loom will probably finalize the structured concurrency API; Leyden plans to ship AOT code compilation; and Amber hopes to present JEPs on constant patterns and pattern assignments. And those are just the most progressed features - more are in the pipeline and discussed in this episode of the Inside Java Newscast.

Welcome to the new Inside Java Podcast. In this meta episode, Nicolai Parlog introduces you to the podcast's new structure with two shows under one umbrella: The long-form conversations you know become Ask the Architects episodes and they'll be accompanied by the Inside Java Newscast as a podcast.

In this special episode of the Inside Java Podcast, Nicolai Parlog talks to Adam Bien about scripting with Java, to Maurice Naftalin about the history and tradeoffs of the collections framework and erasure, and to Tom Cools about the innovative way the Belgian Java User Group organizes itself.

This Inside Java Podcast takes a meta approach. Instead of focusing on specific features, it explores the bigger picture: What are the right problems for Java to tackle? What are the current and future challenges for the Java platform? Why is predictability so important for Java, and what's driving the recent focus on learners and students?

Nicolai Parlog discusses these topics with Georges Saab, Senior Vice President of the Java Platform Group and Chair of the OpenJDK Governing Board.

Java's development embraces the past as well as the future and after contributing to it for over 30 years, John Rose is intimately familiar with the process. In this episode he talks about feature design, the right amount of technical debt (which isn't actually zero), why Rice's theorem demands a mix of static and dynamic checks, how Project Sumatra eventually birthed Panama and Babylon, and more.

In this episode, Nicolai interviews John Rose, Senior Architect of the Java Virtual Machine, who brings over 30 years of experience advancing the Java platform.

Java is a 30-year success story, made possible because its development consistently aligned with users' needs. In its early days, the platform required new features quickly, but over time, minimizing code breakage while carefully evolving the platform became essential. Critical junctures along that path included the introduction of modules and the current strive toward integrity by default.

Nicolai Parlog talks to Mark Reinhold, Chief Architect of the Java Platform, who brings nearly three decades of experience shaping Java's evolution.

OpenJDK projects such as Amber and Valhalla are renowned for their careful and methodical approach to designing and introducing new features to the Java platform.

In this episode, Nicolai Parlog is joined by Brian Goetz, Java Language Architect at Oracle and lead of both Project Amber and Project Valhalla. Brian shares insights and updates on these influential initiatives as they discuss Amber's upcoming feature arc, Valhalla's plans for null-restriction, and more.