G1 is Java's default garbage collector in most environments, and its throughput has been considerably improved in JDK 26 by streamlining its write barriers. This conversation explores the background of that change and dives deep into regions, write barriers, concurrent marking, card tables, and how all that impacts throughput before eventually getting to the improvements made in Java 26, which lay further groundwork to G1 becoming the one and only default collector across _all_ environments.

In this "Ask the Architect" episode of the Inside Java Podcast, recorded during JavaOne 2026, Nicolai Parlog talks to Stefan Johansson, Hotspot Garbage Collection engineer at Oracle.

For more, check https://inside.java/podcast

The Java tool jcmd ("j command") sends diagnostic commands to the JVM, which will react by supplying the desired information: from finalizer queues to heap and thread dumps, from GC insights to virtual thread scheduler statistics. At the moment, this requires a running JVM, but once candidate JEP 528 is adopted, a lot of that information can be seamlessly extracted from a crashed JVM's core dump, allowing easy post-mortem analysis.

Carrier classes are Project Amber's current idea to extend some of records' benefits to regular classes. Probably the most important among them is deconstruction, which would allow classes to participate in pattern matching and reconstruction. In recent weeks, there have been two mails to the Amber mailing list that describe that idea, and in this episode we discuss them both as well as the evolution between them. We also hear why syntax discussions often provide negative value and get a sneak peak at what will likely be the next Project Amber language feature.

Just ahead of the JavaOne speakers dinner, Nicolai Parlog sits down with Brian Goetz, Java Language Architect in Oracle's Java Platform Group, for this "Ask the Architect" episode of the Inside Java Podcast.

Java 26 is getting all packaged up to be shipped worldwide! As with every release of the JDK there are a number of new features, improvements, changes in behavior, and more developers should be aware of before upgrading. In this episode of the Inside Java Newscast we will review all the noteworthy changes coming in Java 26 that will impact developers.

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.