nipafx

Avoiding Final Field Mutation

Nicolai Parlog — Mon, 27 Apr 2026 00:00:00 GMT

Reflective mutation of final field mutation will soon be disabled by default and should be avoided if possible - here's how

The Java language requires final fields to be assigned during object construction and forbids later reassignment, but the JDK nonetheless offers mechanisms that allow just that. JDK 26 takes first steps towards making final fields truly immutable by issuing warnings when they are mutated through the reflection API. JEP 500 explains in detail the rationale and consequences as well as how to use the new command line flags --enable-final-field-mutation and --illegal-final-field-mutation. While they allow the mutation of final fields, this should be seen as a last resort, and projects should move away from that practice.

This article discusses common scenarios in which final fields are mutated through reflection and what alternatives exist for each of them. Since these scenarios can appear in frameworks, libraries, and applications, this article addresses developers of all such projects.

Our guiding star will be the following statement from the JEP on integrity by default, which applies to more than just serialization:

In general, it is a mistake for libraries to serialize and deserialize an object without the cooperation of the object's class.

Note: This article uses serialization as a general term for a mechanism that can turn a Java instance into an external format (e.g. JSON, YAML, or protobuf) and vice versa. For Java's onboard mechanism that revolves around the Serializable interface and the ObjectInputStream and ObjectOutputStream classes, it uses the term platform serialization.

Initializing Instances

Final fields are most often illegally mutated to initialize instances right after construction (as opposed to reassigning them later in an instance's lifetime). This can happen during dependency injection, deserialization, cloning, or other initialization processes that need to create usable instances before handing them over to the user. Some of those use cases are tightly coupled to where the fields' values come from (e.g. from a JSON string or some other serialized form) and we will make these connections in later sections. Nonetheless, there are certain commonalities between these solutions that make it worthwhile to discuss the initialization of instances in isolation.

Ignoring Constructors

It was common for some initialization mechanisms to construct "empty" objects with all-null fields and then assign their values after construction. Java's own platform deserialization works this way (under the hood but also explicitly if readObject is implemented), Java Beans commonly follow this pattern, and so did dependency injection.

This construct-first-assign-later approach collides head-on with final fields, though, for which the Java language promises that they are assigned exactly once during construction (be it in a field initializer, the constructor, or an initializer block) and never modified after. As a consequence, these processes had to resort to forceful assignment, be it via reflection with setAccessible, via Unsafe, or JNI, thus undermining the integrity of the keyword final with all the systemic downsides outlined in JEP 500.

But post-construction assignment (whether the fields are final or not) also has immediate negative consequences for the class itself as it makes it much harder to guarantee that the populated instances fulfill the class’s invariants. These are usually established in the constructor but an initialization process that requires an "empty" constructor or even outright sidesteps it can create ill-formed instances that lead to misbehaving programs or even security vulnerabilities.

Using Constructors

Fortunately, many initialization processes have moved away from this construct-first-assign-later approach. Dependency injection frameworks, for example, now support and often default to "constructor injection", where the values are passed to a constructor that has the task to verify them and then assign them to fields. This not only establishes the class's invariants, it also uses the intended language mechanism to assign final fields and thus solves the problems outlined earlier.

Embracing Constructors

Given the benefits of fully initializing objects through a constructor call, this should not only be the default approach but, unless hard reasons make it unfeasible, the only approach. It is flexible, though, and can take various forms:

If records are used, there is one canonical constructor.
If classes are used, the initialization process can require a single constructor to take that role.
The process can require the user to identify a dedicated constructor or static factory method (e.g. by annotation).
Such a constructor or method doesn't have to be public and can thus be kept out of the type's public API if that's preferable.

A challenge with using constructors or factory methods is getting the argument order right. By default, the bytecode does not contain parameter names, which makes it hard to order the arguments correctly without additional information. That information could come from:

the use of records, whose component names are part of their public API
compilation with the option -parameters, which makes argument names available to the reflection API
the annotation(s) that the user applies to identify the correct constructor or factory method

Note that neither the reflection API nor even the bytecode is guaranteed to report or contain fields in the order they were declared in the source code, so do not try to align field and parameter order.

Platform Serialization

If your code contains Serializable classes, it may use reflection to mutate final fields during deserialization.

In this example, the serializable class Token contains a field derivedKey that must not be reused across application runs and instead be derived with the current run's cryptography configuration. It is hence transient and because Token should be immutable, it is also final:

// This is an example for reflective final field mutation, _not_ for a good
// implementation of the described use case.
// Do _not_ draw any security implications from this code!
public final class Token implements Serializable {

	private static final long serialVersionUID = 7665514043582332374L;

	private final String userId;
	private final byte[] token;
	private transient final byte[] derivedKey;

	public Token(String userId, byte[] token) {
		// verifies and assigns fields and then derives `derivedKey`
		this.derivedKey = Kdf.derive(this.token);
	}

	// implements `readObject` to compute and assign a derived key
	private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
		// side note: before the following method call, this instance has all-null fields
		ois.defaultReadObject();

		byte[] derivedKey = Kdf.derive(this.token);
		// use of reflection to assign `derivedKey` to the field of the same name
		try {
			var derivedKeyField = Token.class.getDeclaredField("derivedKey");
			derivedKeyField.setAccessible(true);
			derivedKeyField.set(this, derivedKey);
		} catch (NoSuchFieldException | IllegalAccessException ex) {
			throw new InvalidObjectException("Failed to set `derivedKey`", ex);
		}
	}

}

There are several options to avoid final field mutation in a situation like this. A number of them follow the guideline to embrace regular constructor invocation:

use a record instead of a class (more on that below)
use readResolve instead of readObject
employ the serialization proxy pattern (which also uses readResolve)

Some other options revolve around the field itself:

remove the field and compute the value on demand instead of on deserialization
remove the field and store the value in an external data structure
make the field non-final

Any of these will remove the need to mutate an otherwise final field.

Serialization

If you maintain a custom serialization process, e.g. as the maintainer of a library that turns Java objects into JSON, YAML, etc., there are several routes you can take to avoid final field mutation. The one that requires the fewest changes on your end is to instruct users to avoid final fields in serializable classes but given their benefits you may prefer to give your users more options.

Limit to Records

A straightforward step is to limit serialization to records - as transparent data carriers, they are a perfect fit for this use case. Their defined protocol for (de)construction allows for straightforward lossless reconstruction of instances, usually without further user intervention like annotations.

Use Records as Proxies

If that is too limiting, a higher degree of freedom can be achieved with a protocol that asks instances to condense their state into a dedicated record instance and to rehydrate from such a proxy. This is akin to the aforementioned serialization proxy pattern and, likewise, these methods don't have be public, although relying on "magic names" (like platform serialization does) is not ideal - using an annotation to identify the to-proxy and from-proxy methods would be the more legible approach. Here's an example what that could look like:

// IN THE SERIALIZATION LIBRARY

// marker interface to quickly identify serializable instances
// (not strictly needed)
interface DataCarrier {
	// defines no methods, so that the serialization protocol
	// doesn't have to be public API
}

// annotations to identify the serialization methods
// (retention policy, possible attributes, etc. are missing)
@interface ToData { }
@interface FromData { }


// ON THE USER'S SIDE

// for some reason not a record
public class Person implements DataCarrier {

	private final String name;
	private final int age;

	// [constructor, methods, etc.]

	@ToData
	private PersonData toData() {
		return new PersonData(name, age);
	}

	@FromData
	private static Person fromData(PersonData data) {
		return new Person(data.name(), data.age());
	}

	private record PersonData(String name, int age) { }

}

Having an explicit external representation like this also makes it straightforward to operate across version boundaries. If the Person class evolves and requires a new serialization format, toData can return an instance of the new class PersonDataV2 but in addition to the new method fromData(PersonDataV2) the old method fromData(PersonData) can remain. If deserialization is still possible, it could still function properly, otherwise it could create a specific error message.

Limit to `Serializable`

Platform serialization is able to write to final fields of Serializable instances and will remain so for the foreseeable future (I'm not aware of any plans to change that). And it offers hooks for external libraries to make use of that capability! This way, it’s possible to turn objects into field values and suitable values into objects, both via their class' serialization protocol. That means your (general) serialization library can instruct users to make their classes (platform) serializable and then you can hook into the process to read and write values to and from (final) fields.

Java makes the methods associated with platform serialization available via sun.reflect.ReflectionFactory, which is considered a critical internal API. Those are available in the JDK-specific module jdk.unsupported and not encapsulated because no supported replacements exist. ReflectionFactory's functionality can only be applied to classes that implement Serializable.

A word of warning: This API is a sharp tool with extra sharp edges and not for the faint of heart. Explaining it in full is beyond the scope of this article.

Here is an example for how to use ReflectionFactory to turn a pair of name and age (which could've been read from any external representation) into an instance of Person. First, the class Person, which is similar to above, but Serializable:

class Person implements Serializable {

	private static final long serialVersionUID = 8127572164613693569L;

	private final String name;
	private final int age;

	public Person(String name, int age) {
		this.name = Objects.requireNonNull(name);
		if (age < 0)
			throw new IllegalArgumentException("Age must be 0 or larger");
		this.age = age;
	}

	@Override
	public String toString() {
		return "Person{name='" + name + "', age=" + age + "}";
	}

}

Because platform serialization deals with input/output streams, an ObjectInputStream is required that is populated with the values that should be assigned to the fields. One way to provide such a stream is to create a custom implementation that reads values from a Map:

static class MapObjectInputStream extends ObjectInputStream {

	private final Iterator<Map<String, Object>> objects;

	MapObjectInputStream(List<Map<String, Object>> objects) throws IOException {
		// create immutable copies of the list and maps
		this.objects = objects.stream()
			.map(Map::copyOf)
			.toList()
			.iterator();
		super();
	}

	@Override
	public ObjectInputStream.GetField readFields() throws IOException {
		if (objects.hasNext()) {
			return new MapGetField(objects.next());
		} else {
			throw new IOException("No more objects");
		}
	}

};

static class MapGetField extends ObjectInputStream.GetField {

	private final Map<String, Object> values;

	MapGetField(Map<String, Object> values) {
		this.values = values;
	}

	@Override
	public ObjectStreamClass getObjectStreamClass() {
		throw new UnsupportedOperationException();
	}

	@Override
	public boolean defaulted(String name) {
		return !values.containsKey(name);
	}

	@Override
	public boolean get(String name, boolean bln) {
		return (boolean) values.getOrDefault(name, bln);
	}

	@Override
	public byte get(String name, byte b) {
		return (byte) values.getOrDefault(name, b);
	}

	@Override
	public char get(String name, char c) {
		return (char) values.getOrDefault(name, c);
	}

	@Override
	public short get(String name, short s) {
		return (short) values.getOrDefault(name, s);
	}

	@Override
	public int get(String name, int i) {
		return (int) values.getOrDefault(name, i);
	}

	@Override
	public long get(String name, long l) {
		return (long) values.getOrDefault(name, l);
	}

	@Override
	public float get(String name, float f) {
		return (float) values.getOrDefault(name, f);
	}

	@Override
	public double get(String name, double d) {
		return (double) values.getOrDefault(name, d);
	}

	@Override
	public Object get(String name, Object o) {
		return values.getOrDefault(name, o);
	}

}

The following compact source file uses the prior classes and ReflectionFactory to:

create an "empty" instance of Person (despite the class not having a parameterless constructor)
populate it with the legal name "John Doe" and illegal age -5 (because the method handle returned by defaultReadObjectForSerialization does not go through the constructor and thus applies no checks)
override those values with the legal pair "Jane Doe"/23 (by invoking the same method handle again)

import module jdk.unsupported;

void main() throws Throwable {
	ReflectionFactory factory = ReflectionFactory.getReflectionFactory();
	@SuppressWarnings("unchecked")
	Constructor<Person> personConstructor = (Constructor<Person>) factory.newConstructorForSerialization(Person.class);
	MethodHandle personReader = factory.defaultReadObjectForSerialization(Person.class);

	var person = personConstructor.newInstance();
	IO.println(person);

	var inputStream = new MapObjectInputStream(List.of(
		Map.of(
			"name", "John Doe",
			"age", -5),
		Map.of(
			"name", "Jane Doe",
			"age", 23)
	));

	personReader.invoke(person, inputStream);
	IO.println(person);

	personReader.invoke(person, inputStream);
	IO.println(person);
}

Platform serialization is an integral part of the JDK and should remain usable without warnings and limitations, so it gets an exception from the rules put forth by JEP 500, but the JDK does not want to disadvantage external serialization libraries and so this exception is extended to them. Consequently, executing the code above issues neither warnings nor errors about final field mutation, regardless of what --illegal-final-field-mutation is set to (including deny). While this may appear like a straightforward way to keep assigning to final fields without limitations (as long as the class is Serializable), this comes with the huge caveat that it adopts all the challenges of platform serialization:

requires a full reimplementation of the protocol (e.g. with regards to readObject and readResolve), which is complex and hard to get right, particularly when it comes to security
relies on the same extralinguistic mechanism that makes it hard for users to guarantee that instances are viable but makes it easy for (intentional or accidental) errors in values to lead to misbehaving instances
proliferates the use of Serializable classes, which, due to the exception from final fields being truly final, will keep suffering from the lack of integrity that JEP 500 sets out to fix (with all the implications for maintainability, security, and performance)

Just like with platform serialization, the seeming simplicity of "just make the class Serializable" requires a lot of complexity elsewhere. Worse, that complexity quickly bleeds into the classes themselves as soon as the serialized form does not map one to one to the fields (e.g. due to evolving the code but being bound to a fixed external form) or deserialization can't simply create instances (e.g. because invariants should be enforced). The lesson to learn from platform serialization is that a more explicit protocol, even if it requires users to write a bit more code, fares better in the long run.

Embrace Constructors

If none of these approaches cover all requirements, the most flexible one is to fully embrace constructors: Read an instance's fields for serialization and let users identify constructors or static factory methods to be invoked during deserialization. This approach requires additional configuration by the user and a more complex implementation, though:

It is necessary to identify fields that should (not) be part of the serialized form.
If the serialized form identifies values by name (like most text-based formats), these can be derived from field names, but that then turns this implementation detail into part of the serialization protocol. Making these names configurable is recommended.
If the serialized form does not guarantee a reliable order (also like most text-based formats) matching values to the deserialization constructor's or method's parameters requires additional configuration by the user.
If the serialized form is order-dependent, the order must be defined by the user as it cannot be inferred from the fields.

Note how records greatly simplify this because their components' order and names are part of their API and they are guaranteed to have a constructor that accepts one argument per component.

Dependency Injection

As mentioned before, dependency injection frameworks often required parameterless constructors, so they could create "empty" instances and then write the dependencies directly to the fields - this is called "field injection" and requires either non-final fields or the reflective mutation of final fields. The ecosystem has largely moved on to constructor injection, where a regular constructor gets called, so that final fields can be assigned therein. If you maintain code that in some way or another injects dependencies, you should probably use constructor injection by default, maybe even as the only option.

Cloning

In some classes that implement Cloneable, the clone() method needs to reassign fields. Common reasons are defensive copies of mutable data structures like collections or the need for a deep copy (Object.clone only creates a shallow copy). If those fields are final, they can't be reassigned after Object.clone returns, though, and so reflective mutation is often used.

In the following example, the list of addresses is mutable and must not be shared across Person instances and so clone() creates a copy that needs to be assigned to the final field addresses, for which it uses reflection:

class Person implements Cloneable {

	private final List<Address> addresses;

	public Person(List<Address> addresses) {
		this.addresses = new ArrayList<>(addresses);
	}

	@Override
	public Person clone() throws CloneNotSupportedException {
		try {
			Person clone = (Person) super.clone();

			Field field = Person.class.getDeclaredField("addresses");
			field.setAccessible(true);
			field.set(clone, new ArrayList<>(this.addresses));

			return clone;
		} catch (ReflectiveOperationException ex) {
			throw new IllegalStateException(ex);
		}
	}

}

Cloning gets no exception from the limitation of final field mutation and so, like in other cases, the use of the reflection API should be avoided. Depending on the requirement that triggered its use, there may be specialized solutions. In the case of defensive collection copies, for example, the constructor could be changed to create unmodifiable copies with List.copyOf, Set.copyOf, or Map.copyOf and then the cloned object can refer to the same collection instance without having to create a defensive copy in the first place.

Such solutions don't generalize, though. The better approach is to avoid cloning entirely (it has other downsides, too) and instead work with copy constructors or static factory/cloning methods, both of which can prepare arguments before assigning them to final fields, which removes the need to employ reflection for that.

Non-Construction Cases

Mutating final fields outside of the creation of instances, particularly of classes other than the one containing the reflective code, should be an extreme exception. Possible reasons could be to circumvent a bug in a dependency or to configure otherwise non-configurable behavior. Such fixes/edits should be considered temporary, though, as any change in the dependency could let that code fail or, worse, trigger misbehavior. It is highly recommended to work towards merging the fix/change into the dependency to make the mutating code superfluous and remove it.

Still, for emergencies like this, the reflection API's capability to mutate final fields remains but needs to be allowed by the application owner through command-line flags. JDK 26 introduces two new options for that:

--enable-final-field-mutation is a permanent option that allows specific modules to mutate final fields
--illegal-final-field-mutation is a temporary option with values allow, warn (default on JDK 26), debug, and deny (future default) that manages how code without specific permission that tries to mutate final fields will be handled

JEP 500 as well as Inside Java Newscast #101 discuss the use of these options as well as their interaction with strong encapsulation in detail, which is particularly important for application maintainers.

You Must Avoid Final Field Mutation - Inside Java Newscast #110

Nicolai Parlog — Thu, 16 Apr 2026 00:00:00 GMT

With JDK 26 / JEP 500 starting to prevent final field mutation through reflection, it is important that Java projects stop employing that practice.

This is Nicolai Parlog. I live at 308 Negra Arooyo Lane, Albuquerque, New Mexico, 87104. To all law anforcement entities, this is not an admission of guilt. I am talking to my community now.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're going to explore how you can keep your project from breaking bad due to the upcoming restriction of final field mutation. This is of immediate importance if you have code that uses reflection like that, maybe for dependency injection or for deserialization. If you don't, it will help you understand why some of your dependencies may change their approach and API in the future. There's a bit more to cover here than fits into a Newscast and so I'll sometimes refer to an article that I've written on this and that either already is or otherwise will soon be published to inside.java - check the description for a link. Ready? Then let's dive right in!

Final Field Mutation

Quick recap on what happened so far: JDK 26 took first steps towards making final fields truly immutable by issuing warnings when they are mutated through the reflection API. JDK Enhancement Proposal 500 and Inside Java Newscast #101 explain in detail the rationale and consequences as well as how to use the new command line flags --enable-final-field-mutation and --illegal-final-field-mutation.

Embedded video.

And while these options do allow the mutation of final fields, this should be seen as a last resort. Frameworks, libraries, and applications should move away from that practice and we're here to discuss how. And that depends on the use case. That could be:

dependency injection
serialization, which in this video I'll use as a general term for any mechanism that turns a Java instance into an external format and vice versa (that external format could be YAML, JSON, Protobuff, whatever)
platform serialization, which I'll use to describe Java's onboard serialization mechanism that revolves around the Serializable interface.
cloning
and general hackery

Let's go over these one by one.

Platform Serialization

We'll start with everybody's favorite punching bag, platform serialization. (By the way, if you want to better understand why everybody bullies serialization but also why it was so vital for Java's success back in the days, check out Billy's excellent StackWalker episode on the topic.) Now, reflection is sometimes used during deserialization to mutate final fields. There are a variety of reasons for that, all somewhat niche, but there are also a number of alternative approaches that you can choose from.

// This is an example for reflective final field mutation,
//  _not_ for a good implementation of the described use case.
// Do _not_ draw any security implications from this code!
public final class Token implements Serializable {

	private static final long serialVersionUID = 7665514043582332374L;

	private final String userId;
	private final byte[] token;
	private transient final byte[] derivedKey;

	public Token(String userId, byte[] token) {
		// verifies and assigns fields and then derives `derivedKey`
		this.derivedKey = Kdf.derive(this.token);
	}

	// implements `readObject` to compute and assign a derived key
	private void readObject(ObjectInputStream ois)
			throws IOException, ClassNotFoundException {
		ois.defaultReadObject();

		byte[] derivedKey = Kdf.derive(this.token);
		// use of reflection to assign `derivedKey` to the field
		try {
			var dkField = Token.class.getDeclaredField("derivedKey");
			dkField.setAccessible(true);
			dkField.set(this, derivedKey);
		} catch (NoSuchFieldException | IllegalAccessException ex) {
			throw new InvalidObjectException(ex);
		}
	}

}

Some are pretty general and they revolve around the idea to replace serialization's extra-linguistic approach of creating a broken instance first and have us fix them later with a regular constructor call that avoids that situation and assigns final fields at the right time, namely during construction. So here are these more general approaches:

you can serialize a record instead of a class, because there platform deserialization does invokle the constructor
you can implement readResolve, which lets you replace the deserialized instance with another one that you call the constructor for

// This is an example for implementing `readResolve`,
//  _not_ for a good implementation of the described use case.
// Do _not_ draw any security implications from this code!
public final class Token implements Serializable {

	private static final long serialVersionUID = 7665514043582332374L;

	private final String userId;
	private final byte[] token;
	private transient final byte[] derivedKey;

	public Token(String userId, byte[] token) {
		// verifies and assigns fields and then derives `derivedKey`
		this.derivedKey = Kdf.derive(this.token);
	}

	// implements `readResolve` to create a new instance
	// with a correctly derived key
	private Object readResolve() throws ObjectStreamException {
		return new Token(this.userId, this.token);
	}

}

you can employ the serialization proxy pattern, which also uses readResolve

If none of those work, there are more situational options for dealing with a final field whose value you want to override - see the article for a short list.

Serialization

When we just now talked about platform serialization, we were the user of that API and had to find options within its logic. Now let's talk about the case where we're maintaining a project or maybe even just some custom code that turns Java objects into an external format like JSON or YAML. That means now we're the ones designing the logic within which our users have to find options that work for them.

Require Broken Classes

The simplest approach for us would be to insist that only classes with a parameterless constructor and non-final fields could be serialized but that would force our users into creating effectively broken classes, so let's look for better options.

Limit to Records

The next one up the complexity ladder would be to limit our functionality to serializing records - as transparent data carriers, they are a perfect fit for this use case. Their defined protocol for construction and deconstruction and the fact that component order and names are part of their API allow for straightforward, lossless reconstruction of instances, usually without further user intervention like annotations.

Use Records as Proxies

If that is too limiting, a higher degree of freedom can be achieved with a protocol that allows serialization of all classes by asking them to implement methods that condense an instance's state into a dedicated record instance and that recreate a class instance from such a proxy. That approach:

lets users assign all fields in a constructor
would give them a lot of freedom
while still allowing us to lean on the power of records

And having an explicit external representation like that also makes it easier to deserialize across version boundaries when the class evolves. As for how the to-proxy and from-proxy methods could be identified, I would recommend not to rely on magic names, like platform serialization does, but to create annotations that users apply to identify them. Note that these methods don't need to be public and so they can stay out of the class' API.

// IN THE SERIALIZATION LIBRARY

// marker interface to quickly identify 
// serializable instances
// (not strictly needed)
interface DataCarrier {
	// defines no methods, so that the 
	// serialization protocol doesn't 
	// have to be public API
}

// annotations to identify the serialization 
// methods (retention policy, attributes, etc.
// are missing)
@interface ToData { }
@interface FromData { }


// ON THE USER'S SIDE

// for some reason not a record
public class Person implements DataCarrier {

	private final String name;
	private final int age;

	// [constructor, methods, etc.]

	@ToData
	private PersonData toData() {
		return new PersonData(name, age);
	}

	@FromData
	private static Person fromData(PersonData data) {
		return new Person(data.name(), data.age());
	}

	private record PersonData(String name, int age) { }

}

Hook Into Platform Serialization

Another option is to hook into Java's platform serialization mechanism by use of the class ReflectionFactory. This API is a sharp tool with extra sharp edges, though, and not for the faint of heart, so I'll skip it here. The article explains on a high level how to do this and also lists all the drawbacks - and there are quite a few.

Embrace Constructors

The last approach I could come up with and the one that offers users the most freedom effectively recreates records' construction and deconstruction protocol but would work for all classes. For serialization, you'd reflectively read all fields and for deserialization, you'd ask users to identify a constructor or static factory method that you call with the values you get from the external format. Then all fields are assigned during construction, which allows the use of final. There are a number of challenges, though:

It is necessary to identify fields that should or should not be part of the serialized form.
If the serialized form is order-dependent, the order must be defined by the user as it cannot be inferred from the fields.
If the serialized form identifies values by name (like most text-based formats do), these can be derived from field names, but that then turns this implementation detail into part of the serialization protocol. Making these names configurable would probably be a good idea.
If the serialized form does not guarantee a reliable order (also like most text-based formats) matching values to the constructor's or factory method's parameters requires additional configuration by the user.

Some of these issues could be solved by convention instead of configuration, but in my experience this often leads to hard-to-predict behavior that causes more issues than it solves. Being explicit often beats being implicit. So the flexibility of this approach comes with a cost.

If I were to write a serialization library today, I would start out with the limitation to records and soon after add the feature that arbitrary classes can be serialized as long as they use a record instance as proxy. It would probably take quite a bit of convincing to allow more flexibility.

Dependency Injection

In the past, dependency injection frameworks often required parameterless constructors, so they could create "empty" instances and then write the dependencies directly to the fields - this is called "field injection" and requires either non-final fields or the reflective mutation of final fields, neither of which is a particularly compelling option. Thankfully, the ecosystem has largely moved on to constructor injection, where a regular constructor gets called, so that final fields can be assigned therein. If you maintain code that in some way or another injects dependencies, you should probably use constructor injection by default, maybe even as the only option.

Cloning

The last situation I want to look at in which final fields may need to be forcefully mutated is cloning. Cloning happens inside a clone method and usually begins by calling super.clone(), which creates a shallow copy of the current instance. But sometimes, this instance needs to be changed before it's ready for wider use, for example to replace a mutable collection with a copy, so the original instance and its clone don't share the same mutable collection. Since none of this happens inside a constructor, if such fields are final, the reflection API seems like the way to go.

class Person implements Cloneable {

	private final List<Address> addresses;

	public Person(List<Address> addresses) {
		this.addresses = new ArrayList<>(addresses);
	}

	@Override
	public Person clone() throws CloneNotSupportedException {
		try {
			Person clone = (Person) super.clone();

			// set mutable copy of address list
			Field field = Person.class
				.getDeclaredField("addresses");
			field.setAccessible(true);
			field.set(clone, new ArrayList<>(this.addresses));

			return clone;
		} catch (ReflectiveOperationException ex) {
			throw new IllegalStateException(ex);
		}
	}

}

But cloning gets no exception from the limitation of final field mutation and so the use of reflection should be avoided here as well. Depending on the requirement that triggered its use, there may be specialized solutions. In the case of defensive collection copies, for example, the class' constructor could be changed to create unmodifiable copies with List, Set, or Map.copyOf and then the cloned object can refer to the same collection instance without having to create a defensive copy in the first place.

class Person implements Cloneable {

	private final List<Address> addresses;

	public Person(List<Address> addresses) {
		// assuming the collection doesn't
		// need to be immutable after all
		this.addresses = List.copyOf(addresses);
	}

	@Override
	public Person clone() throws CloneNotSupportedException {
		// the clone has the same `addresses` instance like the
		// original, but it's immutable, so it doesn't matter
		return (Person) super.clone();
	}

}

Such solutions do not generalize, though. The better approach is to avoid cloning entirely (it has other downsides, too) and instead work with copy constructors or static factory methods, both of which can prepare arguments before assigning them to final fields, which removes the need to employ reflection for that.

class Person {

	private final List<Address> addresses;

	public Person(List<Address> addresses) {
		this.addresses = new ArrayList<>(addresses);
	}

	public static Person copyOf(Person person) {
		return new Person(new ArrayList<>(this.addresses));
	}

}

Embracing Constructors

Everything I said so far could be boiled down to one simple piece of advice: embrace constructors. Every mechanism that creates instances, be it cloning, dependency injection, some kind of serialization, or whatever else, really, should absolutely boil down to constructor calls. They work well with final fields, of course, but they're also the place where classes check their inputs and establish their invariants. Sooner or later, every mechanism that sidesteps that causes problems. Exhibits A and B: Serialization and Cloning.

But what about cases where you need to mutate a final field way after an instance was created? Maybe to work around a bug or to configure some otherwise unconfigurable behavior in code that you do not control. As I mentioned in the intro, the command line option --enable-final-field-mutation exists and this is what it's there for: the cases that have no other solution. But beware that you're taking on technical debt and you should work hard to pay it back, maybe by contributing the bug fix or by discussing the configuration option with the project maintainers. Because one way or another, you will have to repay the debt or your project will be breaking bad.

Watch the video.

Analysing Crashed JVMs - Inside Java Newscast #109

Nicolai Parlog — Thu, 02 Apr 2026 00:00:00 GMT

The Java tool jcmd ("j command") sends diagnostic commands to the JVM, which, at the moment, requires a running JVM, but once candidate JEP 528 is adopted, a lot of the information can be seamlessly extracted from a crashed JVM's core dump, allowing easy post-mortem analysis

A `jcmd` Primer

I just checked and there are about 30 binaries in my JDK 26 install, so I'm not assuming that you know all of them - I surely don't. One that I barely use is jcmd but that's just because I don't debug production applications anymore. If you do, jcmd is super helpful and you should look into it. With it, you can send diagnostic commands to a running JVM and get it to divulge all kinds of behind-the-schenes information, for example:

to see the GC's finalizer queue, which is very handy in preparation for finalization's removal

$ jcmd $pid GC.finalizer_info
# > No instances waiting for finalization found

to create heap and thread dumps; the latter are great to explore the thread relationships established through structured concurrency

$ jcmd $pid Thread.dump_to_file -format=json threads.json
# check threads.json for thread relationships

speaking of virtual threads, you can see what their scheduler is up to

$ jcmd $pid Thread.vthread_scheduler
# > java.util.concurrent.ForkJoinPool@1b9180c2[Running,
#     parallelism = 16, size = 4, active = 1, running = 0,
#     steals = 5, tasks = 0, submissions = 0, delayed = 1]

you also use jcmd to configure, start, and stop the JDK Flight Recorder

$ jcmd $pid JFR.start
# > Started recording 1. No limit specified,
#    using maxsize=250MB as default.
# > Use jcmd 14384 JFR.dump name=1 filename=FILEPATH 
#     to copy recording data to file.

and there's much, much more from basically all moving parts in the JVM

All in all, jcmd is a really useful tool and I recommend you check it out if you haven't already. Or subscribe to this channel, I'll try to get Billy to do a Stack Walker episode on it.

Reviving A Dead JVM's Brain

So let's talk about JDK Enhancement Proposal 528, which is a candidate but currently not targeted to any release. It may make it into JDK 27, but, as always, we need to let the process play out and see what happens.

JEP 528 describes how everyting I just said is fine and dandy but only works with a running JVM. And yet, you're very likely to need that information just after a JVM crashed. And by that I don't mean an application crash due to an uncaught exception or out-of-memory error but a proper JVM crash ("proper fucked"), probably because somebody didn't use JNI correctly or found out where Unsafe got its name from. If the JVM crashes, all you're likely left with is a core dump and while you can extract some information from that with tools like jhsdb, it's too bad that you can't use all of jcmd's power.

"Ha", says JEP 528, "but what if you could"? Let's recreate the JVM's memory image and execute native code in the JVM binary to interpret the data structures in that image. This enables jcmd's diagnostic commands to work exactly as they do in a live JVM, with no changes to the commands or their implementations, but some limitations that I'll get to in a second.

$ java # [... some JVM crashing app ...]
# [... JVM crash info ...] 
# Core dump will be written. Default location: /cores/core.$pid
# [... more JVM crash info ...] 
$ jcmd /cores/core.$pid Thread.print
# > /cores/core.$pid:
# > 2026-03-31 11:27:55
# > [... JDK version info ....]
# > 
# > Threads class SMR info:
# > _java_thread_list=0x0000ffff0c004410, length=17, elements={
# > 0x0000ffff9002a6d0, 0x0000ffff900c4b60, 0x0000ffff900c6380, 0x0000ffff900c7d10,
# > 0x0000ffff900c9520, 0x0000ffff900cad20, 0x0000ffff900cce40, 0x0000ffff900ce7c0,
# > 0x0000ffff9013bf50, 0x0000ffff90148830, 0x0000ffff381e94b0, 0x0000ffff9046a460,
# > 0x0000ffff904c4200, 0x0000ffff904c5880, 0x0000ffff08004250, 0x0000ffff08009380,
# > 0x0000ffff0c0021a0
# > }
# > 
# > "main" #3 [13] prio=5 os_prio=0 cpu=-0.00ms elapsed=18446744073709552.00s
#     tid=0x0000ffff9002a6d0 nid=13 waiting on condition  [0x0000ffff9660d000]
# > [... way more thread info ...]

The JEP phrases this as "reviving" the JVM but I don't think that's a good metaphor because the JVM doesn't really come back to life and, for example, can absolutely not execute any Java code. It's more like briefly reanimating a corpse's brain to access its last memory, meaning this capability is strictly limited to post-mortem analysis of crashed JVMs.

Example & Limitations

When experimenting with this, I created a little example that uses structured concurrency, so we can see something interesting in the core dump, and Unsafe to crash the JVM by accessing an illegal memory location.

void main() throws Exception {
	try (var scope = StructuredTaskScope.open()) {
		scope.fork(asCallable(() -> Thread.sleep(1_000));
		scope.fork(() -> {
			var startTime = System.currentTimeMillis();
			var currentTime = System.currentTimeMillis();
			while (currentTime - startTime < 1_000)
				currentTime = System.currentTimeMillis();
		});
		scope.fork(asCallable(() -> crashJvm());

		scope.join();		
	}
}

void crashJvm() throws ReflectiveOperationException {
	var unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
	unsafeField.setAccessible(true);
	Unsafe unsafe = (Unsafe) unsafeField.get(null);
	unsafe.putInt(0, 42);
}

That immediately confronted me with some limitations of this new capability:

The machine on which the post-mortem analysis is done must have the same operating system and CPU architecture as the system where the JVM crashed.
Since nobody runs macOS in production, this feature is currently limited to Linux and Windows, which was an issue for me because I only have my fruity work laptop with me. Thanks, Ana, for running the experiments on your machine.
I couldn't actually execute jcmd Thread.dump_to_file, which shows structured concurrency relationships in its JSON output, because that specific diagnostic command is written in Java and since this JVM is but a muttering corpse, it can't execute that.

Very few jcmd commands are written in Java, though, so the vast majority that make sense to execute after a crash are available. There are 26 of those and the JEP lists them all:

Compiler.CodeHeap_Analytics
Compiler.codecache
Compiler.codelist
Compiler.directives_print
Compiler.memory		
Compiler.perfmap	
Compiler.queue		
					
GC.class_histogram	
GC.heap_dump		
GC.heap_info		
					
JVMTI.data_dump		
					
Thread.print	

VM.class_hierarchy
VM.classes
VM.classloader_stats
VM.classloaders
VM.command_line
VM.events
VM.flags
VM.metaspace
VM.native_memory
VM.stringtable
VM.symboltable
VM.systemdictionary
VM.version
					
help

In my case, I resorted to Thread.print.

One limitation that one might expect but jcmd successfully avoids is JDK version lock-in. The crashed JDK and the anylsing JDK can be of arbitrary versions as long as they both include JEP 528. If it indeed gets integrated in 27, that means you could, for example, analyze a crashed JDK 27 with jcmd from a JDK 28 and vice versa.

If you don't want to miss the JEP's integration or when some of its limitations get lifted in future releases - it hints at that in its Future Work section - subscribe to this channel. And if you like the feature, Java, or my hiking escapades, give this video a like. I'll see you again in two weeks - so long...

Watch the video.

Java 27 - Better Language, Better APIs, Better Runtime

Nicolai Parlog — Fri, 13 Mar 2026 00:00:00 GMT

Java 25 is the latest release with wide-ranging long-term support. It's a doozy and Java 26 and 27 followed hot on its heels.

Java 25 is the latest release with wide-ranging long-term support. It's a doozy and Java 26 and 27 followed hot on its heels:

from module imports to improved pattern matching
from structured concurrency to HTTP/3
from a simpler main to launching multi-source-file programs
from better performance to quantum-resistant encryption

There are plenty of features in the language, API, and runtime to discuss - whether new, improved, or finalized. So let's go over them!

Towards Better Checked Exceptions - Inside Java Newscast #107

Nicolai Parlog — Thu, 19 Feb 2026 00:00:00 GMT

Java's checked exceptions are both an integral part of the language and one of its most contested features. Let's talk about specific issues with checked exceptions and what could be done about them.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're going to talk about exceptions and what better place to do that than a German train station. So why discuss exceptions and particularly checked exceptions now? Unlike most other episodes, this one is not triggered by a specific proposal. It's kind of the other way around: With Java evolving a lot in recent and coming years, it may well address error handling at some point. But for that conversation to be fruitful, we must move beyond "checked exceptions bad, turn off please" and there are two parts to that:

First, understanding that, within the solution space for error handling in Java, checked exceptions are a net positive. Yes, I like checked exceptions and, more than that, I think it's not just subjective preference but due to objective benefits. But I won't be making that argument here. It has been made countless times before with just as many counterarguments and it takes up a lot of time and energy without getting us anywhere. Instead, we'll be operating from the position that checked exceptions remain an integral part of Java. Because they're beneficial or otherwise because Brian Goetz enjoys our suffering - either way, they're here to stay.

Which brings us to the second part and the conversation I actually want to have, one that I believe would be much more fruitful. Namely, if checked exceptions are so great, why do so many developers dislike them? I mean, even the JDK devs were at some point so flustered that they created UncheckedIOExcpetion. So what are sharp edges and which ones could OpenJDK realistically file off? Let's talk about actionable steps instead of just repeating the same flame war. And this also goes for the comments, by the way.

Ok, with what may well have been the longest Newscast intro ever behind us, let's get going. Ready? Then let's dive right in!

Inherited Checkedness

As you know, whether an exception is checked or not depends on where it sits in the exception type hierarchy: If it extends RuntimeException, it's unchecked; if it doesn't, it's checked. (And, yes, we'll ignore Errors.) Unfortunately, determining this essential property via inheritance collides with other reasons to build a type hierarchy, in this case particularly with unified error handling and access to information.

A good example is SQLException: Catching it allows handling all SQL-related problems that code can be expected to encounter and it gives unified access to error codes and the SQL state. But because it's checked, so are all exceptions that extend it and there are a bunch of them that really shouldn't be. For example, what's the recourse when catching SQLSyntaxErrorException or SQLInvalidAuthorizationSpecException? In almost all situations, an SQL syntax error or invalid DB authentication is a bug in the program and so the exception should be unchecked.

So when creating an exception type as the root for a domain-specific exception hierarchy, you need to decide for all inheriting exceptions whether they'll be checked or not and if you believe in the value of checked exceptions, like OpenJDK does, then you're very likely to err on the side of making them all checked instead of all unchecked. All that to say, it would be great if Java would find a more detailed way to mark exceptions as checked or unchecked; one that allows us to apply that to individual types in a larger hierarchy, for example through a marker interface.

Too Many Checked Exceptions

Because here's the thing: That checked exceptions provide value doesn't mean that they don't have downsides, which means it's important to use them diligently and only where it makes sense for the code calling a method to handle its error. Inherited checkedness is one reason why there are too many checked exceptions, but it's not the only one.

Another is just overly liberal use of them. Take InputStream's and OutputStream's close methods, for example. They throw the checked IOException but what can you possibly do when catching them?

// just a demo (not a particularly useful method)
void closeTheStream(ByteArrayInputStream stream) {
	try {
		stream.close();
	} catch (IOException ex) {
		// What could I possibly do? Close again?
		// Also, the Javadoc says:
		// "Closing a ByteArrayInputStream has no effect."
	}
}

Worse, these two classes and a bunch of their subclasses state that close doesn't even do anything, so they force you to deal with an exception they never throw because some subtype might. No wonder, so many of us dislike checked exceptions!

Suboptimal API design can also lead to checked exceptions being more prominent than they need to be. APIs sometimes bundle functionality where only one part throws a checked exception but without a way to isolate that aspect, every call requires dealing with this exception.

Take JDK methods like String::getBytes, for example: It needs a character set and in the method's initial form, you'd specify the charset by name. But what if no such charset exists? That's why getBytes throws the checked UnsupportedEncodingException.

// throws `UnsupportedEncodingException`
// (particularly annoying: we *know* UTF-8 exists!)
var bytes = "String".getBytes("UTF-8");

So even if the named charset worked well for the other 10 places in your code base, you still need to handle the checked exception here. Ugh! Java 6 fixed this by introducing an overload that takes a Charset instance.

// no exception is thrown
Charset utf8 = // ...
var bytes = "String".getBytes(utf8);

But, interestingly, the static factory method Charset::forName doesn't throw a checked exception. Passing it an illegal name is considered a programming error because there's also the static method isSupported, which you're supposed to use before trying to instantiate a charset.

if (Charset.isSupported("UTF-8")) {
	// declares no checked exception
	var utf8 = Charset.forName("UTF-8");
	// use `utf8`
}

That successfully decreases the checked exception counter by one but the longer I think about it, the less convinced I am that it really improves anything. But that's a thought that needs more time to marinate - maybe fodder for another video.

For now, let's summarize a few things libraries, the JDK as well as others in the ecosystem, can do to improve the situation:

They can revisit which exceptions need to be checked and consider splitting exception types if necessary.
They may also be able to restructure APIs so that operations that throw checked exception are extracted from those that don't, giving users the chance to isolate error handling in fewer places - just like with the charset example.
It may also be possible to buffer error states instead of throwing on every call. An example for this would be PrintStream and PrintWriter, although these classes have other issues.

Catching Unthrown Exceptions

Unfortunately, there's a problem with changing an API to no longer throw a checked exception, namely that such a change is source-incompatible. A try-catch block that catches a specific checked exception demands that something in the try block declares to throw it, which makes the reduction of checked exceptions daunting, specifically for JDK APIs.

try {
	IO.println("Hello, exceptions!");
// "error: exception IOException is never thrown
//  in body of corresponding try statement"
} catch (IOException ex) {
	// ...
}

And it's not like removing a handful of them would move the needle - for this to have a positive impact a decent chunk of checked exceptions would have to turn out to be unnecessary and removed, each of them a breaking change. So it would be really helpful for this approach if the compiler could relax a bit and let us compile code that catches checked exceptions that aren't thrown. This has its own downsides, of course, so it requires careful consideration.

But it would also help with another aspect that makes checked exceptions annoying. As soon as you invoke a method that throws, you need to do something to keep the code compiling. So far so, begrudgingly, good but then, when you're still in the middle of working on that piece of code and comment out a method or move things around and nothing throws the exception anymore, you need to undo all that. So checked exceptions constantly yell at you from the rafters while you're trying to line up your shot. Very annoying!

Functional Error Handling and Deferred Computation

This segment might as well be called "Just use Either" and while that can help, I'd argue that the utility of this advice is pretty limited. This video is already running long, so I'm not introducing how Either works - if you don't know, there's a link to an explanation in the description (#1, #2), right below the like button.

First of all, let's observe that a method that returns a value but can throw a checked exception is functionally the same as a method that returns something like an Either of that value or that exception.

String readString(Path path) throws IOException;
Either<IOException, String> readString(Path path);

But handling an Either vs an exception is of course different and there are two downsides that, in my opinion, make Either a niche solution in Java.

One is that exceptions are much easier to pass up the call stack if you don't want to handle them right there. Just call a bunch of methods and add their exceptions to your throws clause. With Either all those calls need to happen in a functional pipeline and while I like those more than most, I absolutely don't want all my code to be stuck in them.

// chain calls of these two methods
String readString(Path path) throws IOException;
Statement prepareStatement(String sql) throws SQLException;

Statement readPreparedStatement(Path path) throws IOException, SQLException {
	var fileContent = readString(path);
	return prepareStatement(fileContent);
}

// chain calls of these two methods
Either<IOException, String> readString(Path path);
Either<SQLException, Statement> prepareStatement(String sql);

// ① requires functional pipeline
// ② specific exception types disappear
Either<Exception, Statement> readPreparedStatement(Path path) {
	return readString(path)
		// if the either was "left", this does nothing;
		// if the either was "right", it executes the lambda:
		//  - if that succeeds, it returns the result as "right"
		//  - if that fails, it returns the exception as "left"
		// conceptually: "either IOException, SQLException, or a statement"
		.flatMapRight(sql -> prepareStatement(sql))
}

The other, and much more relevant, downside is that Either moves the type information from throws into a generic type and, frankly, that sucks. Because it means that when you chain operations that can throw different kinds of exceptions, say the first an IOException and the second an SQLException, the Either's generic type will quickly escalate to just Exception, which removes a lot of information from the type system. In most situations, this is not an improvement.

But that doesn't mean that there's no room for Either, either. Checked exceptions build on an implicit assumption of immediacy. An operation can throw an exception and because you're calling the operation, you need to handle the exception. But what if you're not calling the operation or at least not directly?

In a stream pipeline, for example, you're passing the operation on and something else executes it later on your behalf.

Stream<String> fileContents(List<Path> paths) {
	return paths.stream()
		// won't compile because `readString`
		// throws `IOException`, but note that
		// it doesn't get executed yet
		.map(Files::readString)
}

// elsewhere...
List<Path> paths = // ...
// `toList` executes the stream pipeline, so if
// `readString` throws any exception it surfaces here
List<String> contents = fileContents(paths).toList();

Now the fact that your operation can produce an error needs to be transported from where you passed it to where you trigger the execution, for example from a Stream::map to its toList. You could try to capture the exception types with generics but you'll run into the same issue I described earlier.

Stream<String, IOException> fileContents(List<Path> paths) {
	return paths.stream()
		// in this hypothetical API, this would compile and
		// the resulting stream carries the exception type
		.map(Files::readString)
}

// elsewhere...
List<Path> paths = // ...
// `toList` throws the carried exception (here: `IOException`)
try {
	List<String> contents = fileContents(paths).toList();
} catch (IOException ex) {
	// ...
}

And the difficulty or sometimes outright impossibility of transporting the error information is why checked exceptions and deferred computation don't work well together.

Note:

This often comes up as "lambdas don't work with checked exceptions" but that's mostly missing the point. Ping me in the comments if you want me to go into more details on that.

End Note.

So checked exceptions struggle with transporting type information from registering to executing a deferred operation. You know what doesn't? Either. Which is why, despite its shortcomings, it's very handy in specific situations like in a stream pipeline.

// use `Either`-returning method for stream pipeline
Either<IOException, String> readString(Path path);

Stream<Either<IOException, String>> fileContents(
		List<Path> paths) {
	return paths.stream()
		.map(path -> readString(path))
}

// elsewhere...
List<Path> paths = // ...
List<String> contents = fileContents(paths)
	// example for processing the stream of
	// `Either<IOException, String>`;
	// here: remove/ignore all error cases
	.filter(Either::isRight)
	.map(Either::getRight)
	.toList();

And I think there are two Java features that could improve this overall problem complex. Admittedly, they are entirely speculative, but hear me out.

One could be the ability of the Java compiler to track multiple checkedexception types in a single generic parameter. That way an Either or a beefed up Stream could easily collect multiple checked exceptions. The language nerd terminology for this would be variadic generics or union types, two different approaches that could achieve similar outcomes for our use case.
The other feature could be a simple way to go from a method that returns and throws to an Either of both and back. Then APIs could stick to declaring return types and checked exceptions but their users could easily switch to a form that works better for deferred computation. This could be a pure library feature but it could also have a language component where try turns into an expression that returns an Either.

String readString(Path path) throws IOException;
Statement prepareStatement(String sql) throws SQLException;

List<Path> paths = // ...
// if Stream<T, EX> could track multple exception types:
Stream<Statement, IOException | SQLException> = paths.stream()
	.map(path -> readString(path))
	.map(sql -> prepareStatement(sql))

// if it were easy to switch to `Either` (say with `try`):
Stream<Either<IOException | SQLException, Statement> = paths.stream()
	.map(path -> try readString(path))
	.map(sql -> sql.flatMapRight(s -> try prepareStatement(s)));

One language change in this space that deserves a mention and does have a JEP draft is for switch to gain the ability to handle exceptions that were thrown by the selector expression. In situations where the error case can be corrected to yield an instance of the same type as the successful branches, this would be very useful. It's essentially try-as-an-expression for recoverable cases. The draft is also linked in the description.

String readString(Path path) throws IOException;

// if `switch` could catch exceptions
String sql = switch (readPath(path)) {
	case String s -> s;
	// map the error case to the empty string
	catch IOException _ -> "";
}

Stylistic Changes

Beyond the changes that could be applied to the language or to libraries, I think our style can change as well.

For example, it has long been accepted that tests just throw whatever exception they encounter. If we write scripts or other small programs, we can just do the same.

For those of us who don't mind functional APIs, we can aggressively replace checked exceptions with Either, Try, or even just Optional. And in situations where nothing can be done about an erro except letting a high-level handler catch it, wrapping a checked exception in an unchecked one is correct and easy to do, too. For any of those options, it's straightforward to create helper methods that wrap method calls accordingly. Yeah, it's not as low effort as a "make everything unchecked" switch but it's also not exactly burdensome.

Or, as we move towards more APIs that rely on pattern matching, we can express some error cases through domain-specific types. Either way, teams absolutely should get together and create a style guide for their project that matches their domain and preference.

But, in the end, I think none of these variants nor the failure mechanisms of other languages, by the way, will be easy to work with if you want to do more than just let errors rip. Because good error handling is hard - inherently. Of course different mechanisms have different tradeoffs and I genuinely believe that some can, in aggregate, be better than others, but that doesn't change the fact that a big chunk of the complexity is essential. An example is the general difficulty to communicate information across stack frames and abstractions (something that plagues logging, too, by the way).

An unfortunate consequence of that is that there is no Pareto principle at play where a few small or easy improvements will yield large results and anybody claiming that probably has not thought about the problem for very long. Instead, it seems that a lot of hard work is required to move the needle. So let's talk about and tackle that hard work. Let me know in the comments what changes you think would make checked exceptions more usable.

Other than that, I'll see you again in two weeks. I need to hurry up and wait to catch my train. So long ...

Watch the video.

Removal of ThreadPoolExecutor.finalize()

Nicolai Parlog — Tue, 10 Feb 2026 00:00:00 GMT

With finalization being deprecated for removal, finalize methods are slowly being removed

Deprecation and Removal of Finalizers

Before the introduction of try-with-resources and the Cleaner API, classes that needed to release resources before their end of life would implement Object.finalize(). The garbage collector invokes this method after an object becomes unreachable and before reclaiming its memory. This process, known as finalization, has a difficult programming model that is prone to unreliable implementation, can cause security vulnerabilities, and negatively impacts performance. It has thus been deprecated for removal in favor of the aforementioned alternatives in JDK 18, as described in JDK Enhancement Proposal 421.

Since then, the number of finalize implementations in the JDK has been steadily reduced. Likewise, the Java ecosystem is required to search for and remove finalize implementations to prepare for the eventual removal of this mechanism. See JEP 421 for details how to approach this.

Removal of ThreadPoolExecutor.finalize()

ThreadPoolExecutor is a non-final implementation of ExecutorService that may be a superclass to executor services in frameworks, libraries, and applications. Its finalize-method has been...

deprecated in JDK 9
re-specified to do nothing (thus leaving it empty) in JDK 11
deprecated for removal as part of JEP 421 in JDK 18

JDK 27 will remove the empty method, which can lead to compile errors in existing code.

Source-Incompatible Change

While Object.finalize() declares that it throws Throwable, ThreadPoolExecutor.finalize() does not. That means calls to ThreadPoolExecutor.finalize(), either directly or by an extending class through super.finalize(), will now implicitly call Object.finalize() and thus encounter a Throwable when they didn't before, which is likely to result in a compile error.

Projects encountering this situation are strongly encouraged to remove this (and other) uses of finalize().

If absolutely necessary, a workaround would be to encase the invocation of finalize() in a try block. Since this ends up calling Object.finalize(), which is empty, the catch block can likewise be empty.

LazyConstants in JDK 26 - Inside Java Newscast #106

Nicolai Parlog — Thu, 05 Feb 2026 00:00:00 GMT

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.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're going to deep-dive into lazy constants, a preview feature in JDK 26. You may already know them as stable values, a preview in 25, which changed not only its name but also its API quite a bit. In fact, this evolution tells us a lot about how OpenJDK develops features from low-level mechanism to higher-level concepts, something I will discuss towards the end of the video. But before that, we'll go over the relevance and challenges of laziness and the LazyConstant and lazy collection APIs. Ready? Then let's dive right in!

Laziness

When we talk about laziness in programming, we don't only mean programmers slacking off while our code is compiling or our Claude is clobbering our code base. It also means to defer computation. Generally speaking, we're more interested in being lazy, in deferring a computation

the longer it takes
the better we can do it with more information
the higher the likelihood that we can get away without needing it at all

In the Java runtime, many processes are lazy, just to name two examples:

Java only loads and initializes classes when the code that is currently executing first references them
it only clears out garbage and frees up memory when empty memory is needed

Our code is also often lazy, usually in ways that are almost too obvious to notice. Of course we don't preemptively load all users from the database or all files in the config folder - instead we wait for such actions to become necessary, usually for specific elements. At the same time, though, our web framework does probably eagerly initialize all controllers before the first request comes in.

And it's not always clear what the right option is because, as most things in programming, laziness comes with trade-offs. Not doing things until you definitely need them means you may produce better results or end up doing less, both of which is good. But only doing things on demand can mean that specific demand takes longer to fulfill, which is bad.

And then there are Java-specific downsides of laziness. Our program's infrastructure is defined by instances that usually refer to one another through fields. Lazily initializing a part of a program thus often means lazily initializing a field and that comes with two specific challenges:

it's more complex code that can be hard to get reliably right, particularly when concurrency is involved
it may prevent the use of the keyword final, which makes code more fragile and harder to optimize because the field can be reassigned later

public class UserController {

	private volatile LoginService login;

	public UserController() {
		// field `login` is lazily initialized
		// by `getLogin` instead of the
		// constructor;
		// that also means, you can never use
		// `login` directly as it may be null
	}

	// one variant to initialize lazily,
	// called "double-checked locking"
	private LoginService getLogin() {
		var login = this.login;
		if (login == null) {
			synchronized (this) {
				login = this.login;
				if (login == null)
					this.login = login =
						LoginService.initialize();
			}
		}
		return login;
	}

}

So, to level the playing field, Java could do with an API that makes lazy initialization easy and gives us as well as the runtime the guarantee that the value, once computed and assigned, remains constant. Enter JDK Enhancement Proposal 526 and lazy constants.

`LazyConstant`

JEP 526 proposes the new type LazyConstant. Instead of creating a final field of type T and computing its value during construction, you'd declare a final field of type LazyConstant<T> and create it with a recipe for that computation. To that effect, you'd call its static factory method of with a Supplier<T>. Then, later, whenever you need the value, you just call LazyConstant.get.

public class UserController {

	private final LazyConstant<LoginService> login;

	public UserController() {
		this.login = LazyConstant.of(LoginService::initialize);
		// using `login` later...
		IO.println(login.get());
	}

}

And that's the whole API. Or at least it will be the whole API in JDK 27, but we'll get back to that later when we'll discuss its evolution. Before that, let's take a closer look at "lazy" and "constant".

As you have no doubt inferred, the supplier you created the lazy constant with, gets executed to compute the value that get returns. But at most once for the first call to get. If there are multiple "first calls" concurrently, only one executes the supplier while all others wait for the result and of course all future calls to get just return that same result. That takes care of the complexity of lazily initializing a field at most once, even under concurrency.

But most experienced Java developers can create a type that does that. What sets LazyConstant apart is not the "lazy" aspect, it's the "constant". Because once the value is computed, it is assigned to a field that is annotated with @Stable, which informs the Java runtime that it will never be reassigned; that it's constant. So your reference to the lazy constant is final and its reference to the value is constant and that opens the door to an optimization called constant folding where a chain of constant references can be shortened to just one load.

Unfortunately, as you may remember from Inside Java Newscast #101, reflection can change final instance fields of regular classes, so they're not actually constant - for the time being, only final static fields, record components, final instance fields in hidden classes, and now LazyConstant values are. But once reflection's superpowers are guarded by a command-line option, all final fields are constant, which will considerably expand the room for this optimization.

Embedded video.

`LazyConstant` Behavior

Ok, rapid-fire round for a few more behavioral properties:

LazyConstant is not serializable.
LazyConstant rejects null, so don't have your supplier return that.
If the supplier throws an exception, it will come out of get and if you try again later, the supplier will be called again - maybe it works better this time. So technically it's not "at most once" but "at most once successfully".
If the supplier ends up calling get in a cycle, you're in trouble but LazyConstant notices and shortcuts this likely infinite loop with an IllegalStateException.
If the supplier blocks indefinitely, you're in real trouble because neither the thread executing it nor any thread waiting for the result will come out of this. The API offers neither timeouts nor cancellations.
LazyConstant really insists on the "lazy" aspect and doesn't want to compute its value when you call equals, so all there is left to compare is the LazyConstant's identity. And, even if it wanted to compute values (and we'll see in a second a related case that requires that), the behavior becomes really hard to intuit real fast. If you want to play this out, leave a comment and we can discuss there.

Lazy Collections

LazyConstant gives you a 1:1 relationship between owning class and needed value, but what if you need 1:n? You could of course declare a LazyConstant<List> but then the whole list needs to be computed at once.

private final LazyConstant<List<String>> list = LazyConstant.of(() -> List.of("0", "1", "2"))

That's probably ok in many cases, but probably less so in others. So JEP 526 also proposes a lazy list and a lazy map, but these are not exposed in the type system. Instead you call List.ofLazy and Map.ofLazy and get a List or Map instance, respectively, that implements the laziness under the hood.

private final List<String> list = List.ofLazy(3, index -> "" + index);
private final Map<Integer, String> map = Map.ofLazy(Set.of(0, 1, 2), key -> "" + key);

For a lazy list, you need to provide the total size and a function that takes an index as input and produces the element at that position. For a lazy map, you provide the key set and a function that takes a key as input and produces the associated value. As you'd expect, the functions are executed exactly once when an element at a given index or for a given key is first needed, even under concurrent access. Beyond this on-demand computation, these collections are unmodifiable and the runtime can apply constant-folding optimizations to code that accesses the content of lazy constants through lazy collections.

Now, for equals, these collections cannot be as blasé as LazyConstant because both List and Map demand a proper implementation and that may require the computation of some values. Which values exactly? All of them if two lists or maps are actually equal...

var eagerList = List.of("0", "1", "2");
var lazyList = List.ofLazy(
	3,
	index -> {
		IO.println("Computing " + index);
		return "" + index;
	});

IO.println(eagerList.equals(lazyList));

/*--< OUTPUT >--*/
// Computing 0
// Computing 1
// Computing 2
// true

... but maybe fewer if they aren't. I looked at the source code and could tell you what happens when, but the Javadoc doesn't specify the behavior, so it's an implementation details, which makes it a fool's errant to rely on it. So I won't. I'll be accepting accolades for my restraint in the comments.

API Evolution

Let me play you a short segment from a conversation I had with John Rose, Senior Architect of the Java Virtual Machine.

We have something called stable variables inside the JDK, which we use all over the place. The things became more and more useful but they were boxed inside of the JDK but that was a necessary step to have something JDK-only - friends and family we call it - until we learn how to use these things correctly and we teach the VM how to optimize them correctly. [Per-Ake Minborg] talked about his StableValue API, which is built on top of these stable variables, and finally we figured out #1 how to optimize them, #2 how to brush them up and make them good for polite company, so that we can put them on the street corner instead of just in our own living room.

And the evolution didn't stop there. As John explained, the JVM has a concept of stable values, which are marked by the aforementioned @Stable annotation. The first step to lifting that into an API for us were stable values in JDK 25. Note that the name was very much based on the low-level concept and its API included the collection factory methods and had a lot of imperative functionality, too.

For JDK 26, the name changed to something more relatable for us and as the concept came into its own, it also became clear that the lazy collections are not primarily lazy but primarily collections and so their factory methods moved over there. And as the concept became clearer, the API dropped a lot of its imperative cruft. Not all, though. In JDK 26, you can still ask a LazyConstant whether it's initialized and you still have an orElse method that lets you handle the case when it isn't. This is a distraction from the intended use case, though, and so JDK 27 will likely drop these methods, which is why we didn't discuss them earlier.

As lazy constants rise to a sharply defined concept, this leaves a bit of a vacuum for more low-level interaction with the @Stable annotation and it's likely that something will fill that. And when it does, we'll of course cover it in an Inside Java Newscast, so subscribe if you aren't already.

I want to leave you with a few more words by John Rose, summarizing this whole process - you can watch the rest of my conversation with him by clicking here. I'll see you again in two weeks and later this year at JavaOne. So long ...

That is a progression that is repeated over and over again for many features. First we find a pain point of something we want to do and we can't do. Then we do something special inside the JDK and teach the JVM about it and then eventually we make an API like virtual threads or stable values or Panama - oh my gosh Panama...

Embedded video.

Watch the video.

Carrier Classes; Beyond Records - Inside Java Newscast #105

Nicolai Parlog — Thu, 22 Jan 2026 00:00:00 GMT

Carrier classes are a generalization of records that allow Java developers to succinctly define classes with a data-centric API that can participate in pattern matching and reconstruction

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and you can consider my socks thoroughly blown. Uhm, that probably sounds weird if you haven't watched the last episode. Let me get you up to speed - here's what my anonymous informant ended on:

Keep an eye on amber-spec-experts, some interesting ideas are coming down the pike about generalizing records and pattern matching to apply to classes and even interfaces. This will also address some of the current restrictions of records, offer a refactoring path to classes, and unblock withers. It will blow your socks off!

And he was right on the money. Brian Goetz, the lead of Project Amber, which is developing these changes, sent out an email titled "Data-Oriented Programming, Beyond Records" that covered a lot of very exciting ground. Most of it was about the addition of a new concept called carrier classes and so they're the main topic of this episode, too. Then, towards the end, I will briefly summarize the rest of the mail as well as Gavin Bierman's on pattern assignments and constant patterns. Ready? Then let's dive right in!

Carrier Classes

In "Data-Oriented Programming, Beyond Records", Brian describes the new concept of carrier classes, which you can view as a generalization of records, or maybe as a less strict variant of them. Because we've all been in the situation where we wanted a type to be a record, but couldn't quite make it one because a requirement collided with a record limitation, most often the need for a hidden field. Which carrier classes can have, by the way, but we'll get to that. Let's stick to records for a moment.

Record Review

The critical ingredient in their effectiveness is their state description through a list of components. This list defines almost all properties of a record and we can group them into two buckets:

one is the record's API: constructor, accessor methods, deconstruction pattern - Brian calls this the state description's external commitment
the other is the record's state representation through fields - the internal commitment

Together with records' insistence on immutability, this complete state description through a list of components defines their core semantics: to be "transparent carriers of immutable data". And this gives rise to all the things we love about them, from their succinctness to their deconstruction through record patterns to their ability for safe reconstruction through a symmetrical construction/deconstruction protocol (with the withers that we don't have yet).

record Point(int x, int y) { }

var origin = new Point(0, 0);
// "wither" as proposed by JEP 468
var moved = origin with { x = 1; };

Semantics

Now let's get back to "normal" classes. Instead of proposing syntax that allows us to haphazardly bolt on deconstruction and somehow mark constructor/deconstructor pairs, or otherwise opt-in to all kinds of record goodies one by one, Project Amber pursued a different goal: To find semantics that are meaningful, albeit less strict than records', and still let the language help. Quote:

Our path here takes one step back [from records] and one step forward: keeping the external commitment to the state description, but dropping the internal commitment that the state description is the representation -- and then adding back a simple mechanism for mapping fields representing components back to their corresponding components, where practical.

And this lead to carrier classes. If records are "transparent carriers of immutable data", carrier classes are just "carriers of data": They have a predictable, data-centric API but don't require their fields to match that and don't insist on immutability - this is the step back from records. Like them, carrier classes are declared with a list of components as a state description and while it doesn't have to be strictly complete, it's still essential that it defines the important state of the class. As Brian puts it:

If we were to extract this state and recreate the object, that should yield an "equivalent" instance.

API Commitment

Syntax details are of course to be determined, so hold your horses on critiquing that until an actual JDK Enhancement Proposal gets filed. For the time being, we'll stick with the strawman syntax in Brian's mail. Here, a class becomes a carrier class by defining a list of components just after the class name. So it looks like a record but with the keyword class instead of record.

// DECLARATION (strawman syntax)
class Point(int x, int y, Optional<String> label) {

	// code missing - would not compile as is

}

And while carrier class semantics are weaker, they're still strict enough to force the components' external commitment: Of course a mere carrier of data needs accessors for that data, a deconstruction pattern to take an instance apart, and a symmetrical constructor to put it back together, and so carrier classes can also be pattern matched and reconstructed.

// DECLARATION (strawman syntax)
class Point(int x, int y, Optional<String> label) {

	// code missing - would not compile as is

}


// USE
var point = new Point(0, 0);
var msg = "at (" + point.x() + "/" + point.y() + ")";

var xCoord = switch (point) {
	case Point(var x, _, _) -> x;
};
// as proposed by JEP 468
var other = point with { x++; };

But, crucially, a carrier class' component list makes no commitment to the internal representation. What fields with what names and types end up backing the external API, how the data flows in through a constructor and out through an accessor - all that is left to us, although as we will see in a minute, we have a shortcut to providing that. But before we get to that, let's see what Java can do for us on the API front.

That deconstruction pattern? We cannot express that in code and there's nothing to customize anyway and so the language provides it for us. And since the component list describes the state, it can also infer implementations for equals and hashCode, but since the fields aren't known, they go through accessors.

// DECLARATION (strawman syntax)
class Point(int x, int y, Optional<String> label) {

	// code missing (would not compile as is):
	//  * requires fields 🧑🏼‍💻
	//  * requires constructor 🧑🏻‍💻
	//  * requires accessors 🧑🏿‍💻

	// derived (like for records):
	//  * deconstruction pattern
	//  * `equals`, `hashCode`, `toString`

}

But the accessors and the constructor, we have to implement ourselves. And this is where the shortcut comes in handy.

Representation

It is expected that the difference between most carrier classes and their "ideal" representation as a record will be small - maybe you just need to return that one list as a stream or store this one derived value. So it would be nice if, instead of having to implement fields, accessors, and constructor arguments for all the boring cases, only that difference needed to be expressed in code. Component fields are the step forward that get us most of the way there because they allow us to succinctly express where the external API maps one-to-one to internal representation.

By declaring a component field, the mail uses the context-specific keyword component for that, we can signal that this field is intended to back the component of the same name and type. Then, the language will provide the accessor and, if we define a compact constructor like for records, will pipe the respective argument into this field. That way, the straightforward portion of the carrier class is not quite as succinct as with records but all you have to do is declare component fields for it.

// (strawman syntax)

// can't be a record because we want to store the
// label in a nullable `String` field and compute
// but not expose the norm (distance from 0/0) for
// a later implementation of `compareTo`
class Point(int x, int y, Optional<String> label) {

	private final component int x;
	private final component int y;
	private final String label;
	private final double norm;

	Point {
		this.label = label.orElse(null);
		this.norm = Math.sqrt(x*x + y*y);
		// x and y get assigned automatically
	}

	// derives accessors `x()` and `y()`

	// `String label` exposed as `Optional<String>`
	Optional<String> label() {
		return Optional.ofNullable(label);
	}

	// `double norm` remains internal

}

That means that we can focus our attention on the rest of the representation. Because every component that is not backed by a component field can be anything you want - go crazy, run wild. And you can also declare additional fields, for example to precompute or cache derived values, but keep in mind that the state description needs to be complete or reconstruction would lead to nasty surprises when important state gets lost.

Beyond Records

Note how I didn't mention final because neither fields nor the carrier class itself need to be. If you're one of those filthy people who like to mutate state, you can absolutely do that. Inheritance is also possible and not entirely trivial, by the way, but I don't have time for that here - please read Brian's mail if you're curious about that. He also talks about carrier interfaces, which I will also punt on.

interface WhatEven(String is, String going, boolean on) { }

Instead I want to leave this topic by going full circle and taking another look at records. Now that you understand the semantics of carrier classes and how they function, records are really just a stricter version of that:

Because records are fully transparent, the internal representation must match the API, so it's as if every component is backed by a component field and no additional fields are allowed.
And because records are shallowly immutable, these component fields are all final.

record Point(int x, int y) { }

// equivalent carrier class
final class Point(int x, int y) {
	private final component int x;
	private final component int y;
}

And there you go: beyond records to carrier classes and back to records.

More Amber Goodies

Ok, let's go over a few more things from Brian's and then Gavin's mail.

Brian also proposes to allow records to be abstract, so that other records can extend them. Truth be told, I'm not entirely sure what to make of that, yet, and am waiting for more details to figure out the use case.

abstract record DataEntry(ZonedDateTime creation) implements Comparable<DataEntry> {

	@Override
	public int compareTo(DataEntry other) {
		return creation.compareTo(other.creation());
	}

}

record UserEntry(ZonedDateTime creation, User user) extends DataEntry { }

He also talked about a relaxation of deconstruction patterns to what I want to call prefix patterns. Such a pattern only captures destructured variables up to the point that it's interested in and elides the rest of the list instead of filling it with underscores.

record Point(int x, int y) { }

switch (shape) {
	// these two patterns would be
	// equivalent (and so couldn't
	// be used in the same switch)
	case Point(int x) -> // ...
	case Point(int x, _) -> // ...
}

That's kinda nice if you want to only match the first of three components but its strength lies on the other end, where components are declared. Because it means that you can append components to a record or carrier class without breaking existing pattern matches. And since we have no way to define our own deconstruction patterns, this is essential to allow at least some evolution of such types.

// you started with...
record Point(int x, int y) { }

var shape = new Point(0, 0);
switch (shape) {
	case Point(int x, int y) -> // ...
}

// and then changed it to...
record Point(int x, int y, int z) {

	Point(int x, int y) {
		this(x, y, 0);
	}

}
// ... and the construction and
// deconstruction above still work

Speaking of defining deconstruction patterns, Brian's mail doesn't say that explicitly, but since carrier classes come with a deconstruction pattern and you could argue that every class that can be de- and then reconstructed is a data carrier and should thus be a carrier class or a record, the need for custom deconstruction patterns lessened. Add in "prefix patterns" and the need shrinks further. And so it makes sense, that there's no mention of how to declare them - it looks like we won't get syntax for that any time soon, maybe never?

Overall, "Data-Oriented Programming, Beyond Records" is not to be misunderstood as a specific proposal, though - that's what the eventual JEPs will do. Instead, it outlines the direction Amber will take in the coming years and describes the semantic constructs it wants to establish. So, ideally, we'll discuss semantics in the comments, not syntax.

As a last comment on that mail, I said "Brian" a lot because he sent the thing but this is of course a team effort with a lot of back and forth between a lot of smart people. All of Project Amber and the wider OpenJDK community deserve credit for this.

The same is true for the next mail, which Gavin sent. He presents the pattern assignments and constant patterns that I went over in the last episode. There's nothing new for us in this mail but it did confirm that my strawman syntax is still the current design and that JEPs are being drafted, so expect those later this year.

Once they're out, we'll of course discuss them here, so make sure to subscribe. And if you give the video a like or leave a comment, more Java developers will get to see it. Speaking of seeing, I hope to see you again in two weeks and in March at JavaOne. So long ...

Watch the video.

Java's Plans for 2026 - Inside Java Newscast #104

Nicolai Parlog — Thu, 08 Jan 2026 00:00:00 GMT

In 2026, Java keeps evolving. Here's how the big OpenJDK projects Amber, Babylon, Leyden, Loom, Panama and Valhalla plan to push Java forward.

This news show has over a hundred episodes but never actually broke any news. Let's change that! I'll tell you a few things about Amber, Leyden, and Valhalla that will make your head spin.

Happy Gregorian new year, everyone, and welcome to the Inside Java Newscast, where we cover recent (and in this case future) developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about Java's plans for 2026 or, more specifically, what the big OpenJDK projects Amber and Babylon, Leyden and Loom, Panama and Valhalla will be working on this year. But before we get started, a few notes:

I'll talk about what features these projects will be working on this year but that by no means implies that they're gonna be released this year, so let's be patient.
If you want to speed things along, you actually can: Find a feature that interests you and is in some form of preview, try it out in as close to production as you can get get, and give feedback.
If you want to follow these developments along, subscribe to this channel, make it a habit to check in on inside.java, or come to JavaOne in March and talk to the very people spear-heading these projects. There's a 50$ discount code in the description.
Also in the description of course, you'll find links to all projects, mailing lists, and everything else I mention in this episode.

Ready? Then let's dive right in.

Project Valhalla

Let's start with the big news. Late last year, I reached out to the people working on these projects to confirm my understanding of what their plans for the year are. What I didn't expect is that a whistleblower came forward to give me inside scoops on Valhalla (mailing list), Leyden, and Amber. This is dangerous business, of course, so I have to keep them anonymous.

You should go download the Valhalla early-access build and send hands-on feedback as we work to polish the implementation for an upcoming release train. The upcoming release train will not be 27, because that's already loading and since we're bringing an elephant on the train with us, we want to make sure we can squeeze into an empty car.

Did you... Have you... Do you know... Do you know what that means? That the reason why it's not 27 isn't that Valhalla isn't ready? 28 might be it, folks. A preview of the first Valhalla feature, specifically JEP 401's value types. The train is coming into view but let's keep our cool - predictions are hard, especially about the future.

Still, I can't wait for summer. In June, JDK 27 gets forked from the main line, which then switches over to 28 with plenty of room for Java's elephantine proposal 401.

After that, the plan is to introduce nullness markers, which will eventually allow the JVM to identify instances of value types that cannot be null and can thus be flattened. Further steps deal with array improvements and the unification of primitives and their value class wrappers, but while work on all that will surely progress in 2026, I see no chance of any of it landing in the main line. Keep an eye Valhalla's early access builds, though - maybe they'll get updated with some of this throughout the year.

Project Panama

It's not just you and me eagerly awaiting Valhalla, the vector API will also be thrilled to see value types because it's also been waiting for them for years. In JDK 26, the API will see its eleventh incubation and it will stay that way until value types ship. Once that happens, the vector implementation will adopt them and the API will be moved from jdk.incubator.vector into a proper java package. The Panama devs will take this opportunity to evaluate all feedback gathered during the API's incubation and polish it a bit, potentially changing a few details or maybe even moving some functionality around.

Other than that, Panama (mailing list) is not that active any more. Don't get me wrong, jextract and the FFM API are still seeing improvements, particularly on the performance side, but since they're now established, that's less "Project Panama work" and more just regular maintenance.

Project Babylon

Project Babylon (mailing list) is currently working on three different pieces. At the core is code reflection, the technology that allows third-party frameworks to reflect over the Java code in a method or in a lambda expression, analyze it, process it, change it, run it - as Java bytecode but also as a GPU kernel, an SQL statement, or on whatever platform the framework wants to. The other two pieces Babylon is working on are proofs of concept that use code reflection to run Java machine learning models on the GPU - one by adapting ONNX, the other by creating a GPU sympathetic Java API that transforms the code to a runtime like CUDA or OpenCL.

Code reflection is coming along nicely and because experience shows that community feedback is easier to get for functionality that ships with the JDK instead of a standalone project EA build, Babylon wants to start incubating code reflection early. So they're already preparing the code for that and are also working on the related JEP. I'm sure we'll hear something about that effort in 2026. The two proofs of concept are really just that and there are currently no plans to turn them into proper projects.

Project Loom

After its revamp in Java 25, the structured concurrency API will preview with only small further changes in 26 and I consider the chances good that it will finalize later this year. This is the last piece of Project Loom's big picture (mailing list) but that doesn't mean there's nothing left to do with regards to virtual threads. Loom is exploring more ways to let us benefit from them but I don't think we'll hear details on that any time soon.

Interlude

Embedded video.

While I have you here, I need to quickly amend my last video about Java's highlights of 2025. Because I kinda forgot a few? Namely these three:

Valhalla published an early-access build in October, previewing JEP 401. No idea how I could forget that.
We launched learn.java, the destination for beginners, students, and teachers of Java.
The playground now comes with snippets - on dev.java it lets you select from a bunch of prebuilt samples to explore a language feature or API; and on learn.java it's embedded into the articles so students can try what they're learning right then and there.

Upgrading from text styled as code to actual code that you can execute with a click of a button right on your browser is really cool! I'm very excited to see how my colleagues Crystal, Jose, and Denis (who built most of the playground, btw; kudos, Denis) will use this. If you want to learn or teach our favorite programming language, check out learn.java.

Now back to the projects - we still got Leyden and Amber to cover and my source has scoops on both.

Project Leyden

Project Leyden's (mailing list) next headline feature will be ahead-of-time code compilation. In JDK 26, the AOT cache contains loaded and linked classes as well as method profiles. With AOT code compilation it would also contain machine code that the JIT compiler generated based on those profiles. That means, in a production run, the runtime can just pull optimized code out of the cache, thus considerably reducing warmup time.

Out of the box, the code cache has very limited portability, though. High-performance code is bound to the exact hardware micro-architecture it was created on and because it contains the garbage collector's write barriers, it's also bound to the GC.

There are three more pieces we're exploring:

Portability of the AOT code cache and the tradeoff entailed between peak performance by targeting the CPU's micro-architecture and portability when optimizing less aggressively.

Iterative training, where an AOT cache acts as an input to a second training run. This will allow frameworks to train the cache and for users to then extend the training by using the first cache in their application training run.

We are also tinkering with inspectability of training data. The information flow from training run to assembly phase is opaque to the end user, especially since we're retiring the ascii-based data dump that drives the assembly phase.

Leyden is also always looking for feedback - on performance as well as on ergonomics. JDK 25 came with the option to execute the first and second step of AOT caching, observing a training run and assembling the cache, as one and 26 introduced an option to make the cache GC agnostic. Give it a try, and let the project know what works for you and what doesn't.

Project Amber

Ok, let's talk about Project Amber (mailing list). Before we get to the juicy bits, a short note on string templates: Work on them is progressing but there are a lot of ideas and it doesn't seem like their convergence is just around the corner, so we'll have to be patient for a bit longer. Still, I hope for at least an official update some time this year.

I cannot go into too much detail or Brian will figure out who I am, but the big picture is that Amber is knee deep in its second pattern-matching phase. Two explorations in particular came along really well and I hope to see JEPs for them later this year:

Constant patterns, which are half-way between old-style switch (int i) case 5... and primitive patterns. In fact, constant and primitive patterns are so intertwined that they'll probably preview and maybe even finalize together.

Pattern assignments, which allow unconditional deconstruction of instances into their components.

But there's more. Keep an eye on amber-spec-experts, some interesting ideas are coming down the pike about generalizing records and pattern matching to apply to classes and even interfaces. This will also address some of the current restrictions of records, offer a refactoring path to classes, and unblock withers. It will blow your socks off!

Phew, I can't wait. If you're as excited as I am and don't want to miss any of these news, subscribe to the channel and let me know in the comments which feature you're looking forward to the most. I'll see you again in two weeks, maybe with a deep dive into Brian's email if it's already out. So long...

Watch the video.

Java's 2025 in Review - Inside Java Newscast #103

Nicolai Parlog — Thu, 18 Dec 2025 00:00:00 GMT

With 2025 coming to a close, let's summarize Java's year and look at the current state of the six big OpenJDK projects as well as a few other highlights.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today - with the end of the Gregorian year fast approaching - we're looking back at Java's highlights of 2025. Or maybe they're just my Java highlights? This will mainly be about what the six big OpenJDK projects accomplished this year. Your Java highlights are probably pretty different - I'm looking forward to reading your comments. And as for what these projects will work on in 2026, I'll go into that in the next episode.

But now, Java's best of 2025. Ready? Then let's dive right in!

Projects Panama and Loom

Let's start with two projects with very different goals that have in common that they already mostly achieved them, so we can quickly check them of the list:

Project Panama wanted to interconnect JVM and native code and finalized the foreign function and memory API already last year in JDK 22. It still has the vector API in the fire, but this is less of a forge and more of a purgatory where vectors have to wait until Valhalla unlocks value types so they can become those.
Project Loom was all about better concurrency and by now delivered most of what it worked on. JDK 25 finalized scoped values and gave the structured concurrency API a do-over that kept it in preview all the way through JDK 26.

So both projects only have a single, mature feature still brewing.

Project Babylon

On the other end of the project arc, we have Babylon, which formed in late 2023 and pushed its first prototype in January 2024. Since then it has diligently worked towards a release, including updates to the prototype, but there are no JDK Enhancement Proposals, yet - not even in draft. Babylon's goal is "to extend the reach of Java to foreign programming models such as SQL, differentiable programming, machine learning models, and GPUs", obviously the last two of those are the current focus. Babylon wants to achieve that with code reflection and the Heterogeneous Accelerator Toolkit (HAT for short) - I'll explain how in the next episode. If you cannot wait that long, check out Gary Frost's talk from JavaOne 2025, which brings me to a highlight of my year.

JavaOne

JavaOne is not just any conference - it's the Java conference. Or at least it's supposed to, but, frankly, Europeans are much more eager to go to Java conferences than US Americans are right now and so European conferences dwarf what's taking place in the States. But even a smaller JavaOnce is special. For me because I'm involved but also for the larger community because it's the only conference where you'll meet all the Java architects. And I'm not just talking about Brian Goetz or Stuart Marks, either. In 2025 we also had Mark Reinhold, John Rose, Ron Pressler, Viktor Klang, Per-Ake Minborg, and so many, many more. Of course there'll also be sessions by community luminaries like Venkat Subramaniam and Josh Long. If you want to dive deep into where Java is today and where it's going tomorrow, this is the place to be.

For 2025, that chance has passed, but we got all the talks in a playlist, linked in the description. For 2026, I got good news for you! Ticket sales are open and currently discounted but if you order before December 23rd, you'll also get a free, limited-edition JavaOne backpack. But wait, that's not all - if you go to javaone.com now and click register to buy a ticket, you get my personal permission to tell Billy how ridiculous his hair looks when you come to the Bay Area in California from March 17th to 19th. I'll see you then.

Project Amber

Project Amber differs from other OpenJDK projects in that it doesn't have a specific goal that it wants to accomplish and then shut down. Instead, it looks at the whole language and aims at making it more expressive and thus our code less verbose. As such it introduced a lot of features over recent years, like, a lot, but they're not completely arbitrary, either. A bug chunk of them fall under pattern matching, with the on-ramp being a second, smaller category.

In 2025, Amber shored up the remaining work in these categories:

for pattern matching it progressed the preview of primitive patterns in JDKs 25 and 26
for the on-ramp, JDK 25 finalized compact source files, simplified main, and module imports
the mostly stand-alone feature of flexible constructor bodies also finalized in JDK 25

That means, with primitive patterns, Amber is currently only previewing a single feature - something that hasn't happened since JDK 18. So you can really tell that, in 2025, Amber is transitioning from its phase 1 that focused on pattern matching and the on-ramp to a phase 2 and we'll see in the next episode what that will be about.

Project Leyden

Only two and a half years after its inaugural mail to an OpenJDK mailing list, Project Leyden started shipping features in 2025. JDK 24 introduced the ahead-of-time cache, containing loaded and linked classes, and 25 added method profiles to it and simplified the cache creation process by allowing us to fuse the observation of a training run and the assembly of the cache into a single step. If you want to understand how to apply this at scale, at JavaOne 2026, Danny Thomas and Martin Chalupa will tell us how they're putting it into practice at Netflix. Getting the AOT cache off the ground was definitely a highlight of 2025 and I'm curious to see what Leyden will accomplish next year.

As a bit of a preview for that, Leyden also released an early-access build in August of this year. It contains a lot more optimizations than current JDKs and can reduce startup time by 60 to 75%. There's a link in the description if you want to kick the tires.

Java 25

With Amber and Leyden pushing a number of features into JDK 25, it has been another great release. Add on top that Oracle and other vendors offer long-term support and we got another highlight of Java's year. In fact, we in the DevRel team were so enthusiastic about Java 25 that we created the RoadTo25 video series that goes over pretty much everything that changed between 21 and 25. Beyond that, a bunch of us traveled to Redwood Shores to live-stream the release from there with a bunch of great guests from OpenJDK as well as the wider Java community. Those live streams are always a highlight of my year, I love those. There are links to RoadTo25 as well as to the live stream in the description.

Embedded video.

Deprecations

2025 was also pretty big on removals:

JDK 24 permanently disabled the security manager
JDK 25 removed the remaining 32-bit ports
JDK 26 will remove the applet API

Particularly the first two will considerably reduce OpenJDK's maintenance obligations and allow it to spend more resources on moving Java forward.

There was also progress towards integrity by default:

the memory access methods of sun.misc.Unsafe issue warnings when invoked
reflective mutation of final fields starts requiring command-line options

I gotta say, the longer I hang around OpenJDK, the more I appreciate this kind of work. Maybe my highlight of 2025 is disabling the security manager. Analyzing the ecosystem's costs and benefits of this decision, communicating its removal, withstanding a bit of pushback, and patiently executing a year-long plan - that's pretty impressive.

Project Valhalla

That leaves us with Project Valhalla. How much I wish I could tell you that this was the year where it started shipping features - that would've definitely been my highlight, but... it wasn't. The path forward is pretty clear now, though:

introduce value types - that's JEP 401
allow null-restriction
take primitives as close to non-nullable value types as possible - that's JEP 402

Will we see any of that in 2026? I don't know but I will make a guess in the next episode. Which is scary to say because I don't know yet which way I will guess and I doubt any new information will come to light in the next couple of weeks. So, tune in to watch me embarrass myself, I guess.

Until then, have a great end of the Gregorian year, enjoy your time off if you take any, let me know in the comment what your Java highlight of 2025 was, and I'll chat with you down there. Otherwise, I'll see you again in 2026. So long...

Watch the video.

All Features in Java 26 - Inside Java Newscast #102

Nicolai Parlog — Thu, 04 Dec 2025 00:00:00 GMT

Java 26 enters rampdown phase 1, which sets its feature set in stone: HTTP/3 support, performance and AOT improvements, new command-line flags to manage final field mutation, and more

What are you doing here? I said not to click. Yeah, JDK 26 is entering dampdown phase 1 today and its feature set is frozen, but it's just HTTP/3, better G1 performance, and a new AOT feature. Oh, and new command-line flags about final, changes to structured concurrency and stable values, sorry lazy constants, and... Ok, I can finish this later. Jeez!

HTTP/3 Support

Starting with JDK 26, Java's HttpClient supports HTTP/3. At the API level, this addition is tiny: You can now pass the new HttpClient.Version enum value HTTP_3 to the builder method version when building an HTTP client or request. You then go on to use the built instances as you normally would and almost everything else happens beneath the surface.

var client = HttpClient
	.newBuilder()
	.version(HttpClient.Version.HTTP_3)
	.build();

var request = HttpRequest
	.newBuilder(
		URI.create("https://openjdk.org/"))
	.version(HttpClient.Version.HTTP_3)
	.GET().build();

var response = client
	.send(request, BodyHandlers.ofString());

But unlike HTTP/1 and /2, /3 is based on UDP instead of TCP, which means you cannot easily upgrade an existing connection. Consequently, there's no obvious version for the initial connection, which makes it a bit tricky for the API to determine what HTTP version to use. JDK Enhancement Proposal 517 explains the process in detail, so give that a read to understand its tradeoffs and how to configure it.

Improved G1 Performance

In videos like this one, where I summarize all changes in a new Java release, I do my best to present each topic succinctly, so we're not here for 40 minutes, but with enough details that you get an idea of what's going on. Only, some changes seem purpose-built to eliminate that middle ground and this is one of them.

Here's the short version: JDK Enhancement Proposal 522 improves the throughput of Java's default garbage collector G1 by reducing contention and synchronization over an essential data structure called the card table. This leads to performance gains of anywhere between a few and up to 15%, depending on how heavily the application modifies object-reference fields.

The more detailed version needs to explain some garbage collection basics, how a regional garbage collector works, what a card table and write barriers are, and how the just-in-time compiler is involved and all that before even getting to JEP 522.

Ain't nobody got time for that.

Exactly! I mean, if you do, check out Inside Java Newscast #99, but everybody else, let's move on to the next feature.

Embedded video.

AOT Caching With Any GC

As of JDK 26, Project Leyden's ahead-of-time cache does not contain any instances of your classes. But it does contain instances of JDK classes, most prominently of Class for classes that were loaded and linked during the training run and of anything they reference, such as strings and arrays. So far, these instances were stored in a GC-specific format that allowed using the cache together with Serial GC, Parallel GC, and G1, but notably not ZGC. For compatible GCs, the cached objects were mapped directly into memory, which is really fast if the cache file was in the filesystem cache.

To make AOT caching compatible with ZGC, JEP 516 introduces a GC-agnostic format for cached objects. Now, this can not simply be memory-mapped. Instead, objects are streamed into memory by a background thread, so the GC can lay them out according to its rules. This requires some CPU time but allows the startup process to continue, which can actually make the startup faster than memory-mapping a cache file that's not in the filesystem cache. So besides GC-compatibility, there's also a performance tradeoff here.

You can select GC-specific vs agnostic format with -XX:+/-AOTStreamableObjects and the JEP also describes a heuristic for what format is chosen when and I strongly recommend to give it a read if you're interested in improving startup time.

And that's it for new final features. Yes, three, I told you not to click! Let's move on to removals and then previews.

Applet API Removal

It is kind of amusing to note that Java managed to succeed despite having gotten almost all the defaults wrong. Right? That references are nullable by default, that fields are mutable by default, that the default visibility is not private, that classes are extensible by default, right? So we got all the defaults wrong and yet, still, somehow, Java was a successful language and people still wanna program in it.

That was Brian Goetz in a conversation I had with him for Java's 25th birthday in 2020 - there's a link to that segment in the description. The gist of what Brian was saying is that Java's initial design was shaped by influences and ideas that were en vogue at the time, but as times change quite a few of those didn't age well. But while it's easy to look back at them from the present and consider them mistakes, that's a myopic perspective. Quite a few of those "mistakes" were integral parts of Java's early success and, without them, there might well be no Java around today.

One of those "successful mistakes" was serialization, but we're not talking about that today. Another were Java applets - little Java programs that you would download alongside HTML in bytecode form, that the Java browser plugin would run on a local runtime, and that could interact with the rest of the page. Basically the JavaScript of the late 90s. By the way, in a cosmic coincidence JavaScript turns 30 today - welcome to the old people club, JS.

As JavaScript won out, browsers dropped support for powerful plugins like applets and so they became essentially unused. JDK 9 deprecated them and now, a mere nine years later, JDK 26 removes them. It will be the first Java SE release without the java.applet package. If you're one of the unlucky few to still be using it or are interested in a bit of Java history, check out JEP 504 and Phil Race's recent article on inside.java.

Oh, and JavaScript, applets didn't quite make it to their 31st birthday. Just saying, in case you want to start putting your things in order.

Reflective Mutation Of Final Fields

Another almost-original sin that Java is working on fixing is the non-finality of the keyword final:

void main() throws Exception {
	var box = new Box("element");
	IO.println(box); // ~> "[element]"

	var elementField = Box.class
		.getDeclaredField("element");
	elementField.setAccessible(true);
	elementField.set(box, "new element");

	IO.println(box); // ~> "[new element]"
}

class Box {

	final String element;

	Box(String element) {
		this.element = element;
	}

	public String toString() {
		return "[" + element + "]";
	}

}

In a future release, reflective mutation of final fields will fail unless explicitly allowed with the command-line option --enable-final-field-mutation. Now, in JDK 26, it's still possible but you'll get a warning. That behavior can be managed with the temporary option --illegal-final-field-mutation:

allow lets you mutate final fields
so does warn, which is the default on 26, but you'll get one warning per mutating module
debug is like warn but for every mutation and with more details
and finally, deny simulates the future where such mutation leads to an exception

For more details, check out JEP 500 or the last Inside Java Newscast and if you're maintaining a code base that mutates final fields through reflection and are wondering what your alternatives are, keep an eye on inside.java - I'm currently in the middle of writing a detailed guide for that specific scenario.

Embedded video.

Primitive Patterns

Primitive patterns allow us to check whether a primitive value can be losslessly represented by a different primitive type. For example, can a given long l be an instance of int? Yes, if it's in the range from -(2^31) to 2^31-1. Can the same long be represented by a double or even a float? Now it gets more complicated.

long l = // ...

// is this the same number?
int i = (int) l;
double d = (double) l;
float f = (float) l;

But thanks to primitive patterns all of those are simple checks, whether with instanceof or in a switch, for example when deconstructing records. Then you can ask whether that, JsonNumberNode for example, contains a number that fits into an int.

// use primitive patterns to check
if (l instanceof float f)
	// use `f`

switch (jsonNode) {
	case JsonNumberNode(int n) -> // ...
	case ...
}

JEP 530 previews primitive patterns for the fourth time, trying to get the edge cases just right that are bound to pop with something tricky like an 8-by-8 conversion matrix between types plus the ability to match on specific values. As an example for what changes in JDK 26 consider switching over a byte and having a label case short s followed by case 42. Since 42 can be expressed as a short, if the variable is indeed 42, case short s will apply - this label dominates case 42, which is effectively unreachable.

byte x = 42;
switch (x) {
	case short s -> // ... | applies for x=42
	case 42 -> // ...      | unreachable ⛔
	// ...
}

JDK 26 assumes a dead label like this is a mistake and won't compile. If you want to learn more about details, like "type-based unconditional exactness", give the JEP a read.

Embedded video.

PEM Texts

A common way to exchange keys or certificates, particularly when a squishy human is involved, is to use the text-based PEM format.

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj
0DAQcDQgAEi/kRGOL7wCPTN4KJ
2ppeSt5UYB6ucPjjuKDtFTXbgu
OIFDdZ65O/8HTUqS/sVzRF+dg7
H3/tkQ/36KdtuADbwQ==
-----END PUBLIC KEY-----

The JDK comes with all the building blocks to turn these texts into cryptographic objects and vice versa but that required a decent amount of custom code. Starting in JDK 25, Java previewed an API that makes these transformation much easier:

First, you create a PEMEncoder, then call encode with an instance of the new interface DEREncodable, which types like AsymmetricKey and X509Certificate extend. And then you can then store or send the resulting byte array or string. On the other end, a PEMDecoder instance can decode from a string or input stream and return a DEREncodable instance that you can pattern match over.

X509Certificate cert = // ...

var pe = PEMEncoder.of();
var pemString = pe.encodeToString(cert);

var pd = PEMDecoder.of();
DEREncodable crypto = pd.decode(pemString);

Alternatively, you can specify to decode what exact type you expect and then either get that back or an exception:

X509Certificate cert2 = pd
	.decode(pemString, X509Certificate.class);

You can also encrypt these objects and configure an alternative cryptographic provider:

PrivateKey key = // ...
char[] password = // ...

var pe = PEMEncoder
	.of()
	.withEncryption(password);
byte[] pem = pe.encode(key);

var pd = PEMDecoder
	.of()
	.withEncryption(password);
PrivateKey key2 = pd
	.decode(
		new ByteArrayInputStream(pem),
		PrivateKey.class
	);

In JDK 26, JEP 524 previews the API for a second time with a few changes, most notably the added support for KeyPair and PKCS8EncodedKeySpec.

Embedded video.

Lazy Constants

Another API that sees its second preview in JDK 26 are stable values. Or rather lazy constants because while the API's core functionality (to provide exactly-once lazy initialization with great run-time performance) remains, its surface sees major changes, all the way to its name. So much moved around that I'll dedicate another Newscast to it, either in two weeks or next year - subscribe if you don't want to miss it. If you can't wait that long, check out JEP 526.

Structured Concurrency

After the structured concurrency API saw a big revamp in JDK 25, 26 is refining that new version and sending it out for another preview with a few small changes, most of them to the Joiner interface:

it can now implement onTimeout and thus do some cleanup and define what exception should be thrown in that case
allSuccessfulOrThrow() now returns a list of results rather than a stream of subtasks
anySuccessfulResultOrThrow() dropped "result" from its name and it's now just anySuccessfulOrThrow()

As with all preview language features and APIs, if you want them sooner rather than later, the best way to get them to finalize is to try them out in as close to a production environment as you can and give feedback on the respective mailing list with what worked well for you and what didn't.

Vector API

And that's it for today on the Inside Java Newscast. Have fun with Java 26, I'll see you again in two ...

door opens

Yeah?

Haven't you forgotten something?

No.

But the Vector API...

I said "no!". I have not forgotten that, I skipped it intentionally.

But shouldn't you explain to your audience why

No, we're not doing this - out. Out!

Watch the video.

Java 26 Warns of Deep Reflection - Inside Java Newscast #101

Nicolai Parlog — Thu, 20 Nov 2025 00:00:00 GMT

Java 26 will issue run-time warnings when a final field is mutated through reflection. This prepares a future change that will make such final field mutation illegal by default to improve Java's integrity.

There's a big change beginning in Java 26 that you'll have to react to in all likelihood: No more reflective mutation of final fields! Finally!

And, yes, lame jokes involving the word "final" are par for the course here. Nothing I can do about that, I don't make the rules. But I will enforce them in the comments, so you better...

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about how Java 26 will take the first step towards disallowing reflection from mutating final fields. This change may require you to add a command-line flag or two, update the odd dependency, or, in the long run, maybe even migrate away from one. We'll start with what you need to do before looking at the bigger picture and a bit of history on deep reflection. Ready? Then let's dive right in!

Final Field Mutation

As you know, the language does not allow mutating final fields - they must be assigned exactly once during construction and that's it.

void main() throws Exception {
	var box = new Box("element");
	// compile error:
	//  "cannot assign a value to final variable value"
	box.element = "new element";
}

class Box {

	final String element;

	Box(String element) {
		// assignment is enforced
		// (in declaration, initializer, or constructor)
		this.element = element;
	}

	public String toString() {
		return "[" + element + "]";
	}

}

Then you can rely on the invariants you established for correctness and for security and the just-in-time compiler can aggressively optimize through those immutable fields for performance. Is what you'd think. But, alas, reflection can still change that field. After fetching it and a swift call to setAccessible(true), calling set will mutate the presumably immutable field.

void main() throws Exception {
	var box = new Box("element");
	// prints "[element]"
	IO.println(box);

	var elementField = Box.class.getDeclaredField("element");
	elementField.setAccessible(true);
	elementField.set(box, "new element");

	// prints "[new element]"
	IO.println(box);
}

At least in Java, the question what happens when an unstoppable force hits an immovable object has a clear answer but for reasons already alluded to and explored in more depth later, it's fair to say that it's the wrong one. And JDK Enhancement Proposal 500, which is already integrated into JDK 26, sets out on a path that changes that.

Let's start with a look at what lies at the end of that path: Without further command-line options, a final field will be truly final. Neither use of the language nor of any API nor even JNI will be able to mutate it after construction. Ideally, no code will want to, either, and all libraries and frameworks that do that today have moved to different approaches, which are outlined or at least linked in the JEP. Nonetheless, if code insists on changing such fields, there are two steps you, as the application developer, have to take.

Step 1 is to ensure that the field is not encapsulated from the reflecting code. If the field is on the class path, part of its module's public API, or field and reflecting code are both in the same module, then that's already the case. But if the field is not public API and in a module other than the reflecting code, you need to open the former to the latter with the command-line option --add-opens. Either path allows the setAccessible call to go through and thus the mutation of non-final fields through reflection. This has been required since modules were introduced in Java 9, so it's not exactly new.

What's new is step 2: Allow the reflecting code to change final fields. You do this by adding the command-line option --enable-final-field-mutation with either ALL-UNNAMED if the reflecting code is on the class path or otherwise with its module name. Note that you can only refer to modules in the boot module layer - it's not possible to enable final field mutation for code in user-defined layers.

So, taken together, to reflectively mutate a private final field in a module, you need to --add-opens (to ignore private) and to --enable-final-field-mutation (to ignore final). You're most likely to pass these as command-line options but

you can also add them to the environment variable JDK_JAVA_OPTIONS
you can put them into an argument file that you reference with @
for executable JARs, you can add it to the manifest
or you can configure your custom runtime via jlink's --add-options flag

Once the next JDK 26 early access build ships, you will be able to use --enable-final-field-mutation and set everything up for the glorious future, where final means final - at least by default. So that's the destination - now let's have a look at the path that takes us there.

Migration Path

As with prior developments where Java changed its stance, or at least its default position, final being truly final will be introduced gradually with help of a temporary command line option just like --illegal-access for strong encapsulation and --illegal-native-access for restricted JNI or FFM operations. This new option allows you to forego changing your code, fiddling with your dependencies, or working out the exact modules that reflect over final fields and give blanket permissions - or blanket vetos actually, as we'll see. It's called --illegal-final-field-mutation and has four well-known values:

The first one is allow and makes final field mutation "just work". Although the reflecting code still needs access to the field, which may require an --add-opens as explained earlier.

The second value, and the default on JDK 26, is warn, which will do just that. Final field mutation will succeed with one warning per reflecting module getting printed to the error stream. The warning will identify the field that is being reflected over and the method that is doing it.

WARNING: Final field $field in $class_1 has been mutated by class $class_2 in module $module
WARNING: Use --enable-final-field-mutation=$module to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled

The third value is debug, which also allows the mutation and prints the same message as warn plus a stack trace and for every illegal mutation, not just the first one from any given module. As an aside, if you want maximal visibility into final field mutation, you can also enable the JDK Flight Recorder and observe the event jdk.FinalFieldMutation.

Finally, we have deny, which leads to exceptions. The JEP as well yours truly recommends this from day one because it forces you to look into all offenders and to prepare for the value to become the inevitable default of this option.

The funny thing about the permanent option --enable-final-field-mutation and the temporary option --illegal-final-field-mutation is that while the latter offers blanket access and thus seems to promise fewer hassles in the short term, you may also only need one --enable-final-field-mutation. Because if the reflecting code, even if spread across many JARs, is all on the class path, --enable-final-field-mutation=ALL-UNNAMED is all you need to enable all of it - so you might as well not bother with the temporary --illegal-final-field-mutation.

And before you get giddy that not adopting modules saved you work, it'll also save you from much of the benefits of making final fields final because now you're telling the runtime to make an exception for the entire class path, which apparently includes your application and all dependencies. So, joke's on you - no extra performance for you!

Odds & Ends

Before we get to performance and other benefits in a second, I want to briefly touch on a few points:

If the code calling setAccessible and the code doing the actual mutation through set are not in the same module, the situation becomes a bit more complex but the JEP has you covered - see the section The deep reflection API.

// module A makes field accessible
var field = Box.class
	.getDeclaredField("element");
field.setAccessible(true);

// module B sets a new value
field.set("new element");

If you use reflective final field mutation in a clone implementation along an inheritance hierarchy, then be warned that this case gets no exception. You either need to enable final field mutation on the command line or, and this is the preferable option, solve the problem some other way, either by implementing clone with constructor calls or by outright replacing it with static factory methods.

class Box implements Cloneable {

	final String element;

	Box(String element) {
		this.element = element;
	}

	// `clone` that makes changes through reflection
	public Box clone() throws CloneNotSupportedException {
		var clone = (Box) super.clone();
		try {
			// try to make field value lower-case
			var elField = Box.class.getDeclaredField("element");
			elField.setAccessible(true);
			elField
				.set(clone, element.toLowerCase());
		} catch (ReflectiveOperationException _)  {
			// ignore error
		}
		return clone;
	}

	// alternative `clone` that goes through the constructor
	public Box clone() {
		return new Box(element.toLowerCase());
	}

}

Then, if you use reflective final field mutation for deserialization, check out the JEP's section on ReflectionFactory. This API allows you to execute an object's deserialization protocol so you don't need to assign the field after the fact and need no extra command-line flags.

And lastly, if you're the developer of a library that uses deep reflection to mutate potentially final fields, you should really try to move away from that. There are a few paths that you can take that are outlined in the JEP draft for integrity by default - there's a link to that section in the video description right under the like button. Although, maybe more important to you specifically, the dislike button is also right there. If none of those approaches work for you, reflection remains the last resort, but it requires your users to enable final field mutation and you to convince them that it's worth the trade-off.

So let's talk about the benefits of final finally meaning final.

Integrity By Default

If you've been following Java's development closely or just listened carefully to what I said so far, you probably already know where all this coming from - or rather where it's leading: integrity by default. In this case the integrity of final as a keyword. It promises immutability after the initial assignment and yet there's an API that undermines that very guarantee, so if push comes to shove, nobody can actually rely on final fields not getting reassigned.

Not you when something quirky is going on and you're trying to understand a program's data flow.
Not the forensics expert who has to figure out how the attacker made the program misbehave.
And not the just-in-time compiler who desperately wants to constant-fold across final fields, among other optimizations.

So not being able to rely on finality has material downsides, which is why final fields of hidden classes and of records, introduced in Java 15 and 16, respectively, could never be changed through reflection. And with integrity by default for final, the same will be true for regular classes' fields. Unless certain command-line options are used, like in this case --enable-final-field-mutation, we can rely on Java's promises, which improves maintainability, compatibility, security, and performance.

Of course this begs the question why exceptions like the one for final field mutation were made in the first place and I don't think there's a aingle answer to that. From what I gathered from all that was written about strong encapsulation, unsafe memory access, finality, etc. I got the impression that there are a few things at play.

Most obviously, there was often a feature in development that seemed to demand an exception from the rule and that was important enough to make one. And who else could be at fault in the case of final field mutation than our old nemesis serialization, whose protocol basically demands assigning to an empty object's final fields, and so JDK 5 changed the reflection API to allow just that.
I think another factor is that OpenJDK did not always have the opportunity to research alternative approaches. After all, it takes resources and persistence to hold back a feature that is already functioning to keep working on it to prevent downstream issues. In this case it took until Java 7 before method handles were introduced, which underpin the possibility to execute a class' deserialization protocol, so the fields don't have to be assigned after the fact.
Finally, I believe the understanding that these exceptions not only have individual downsides but coalesce into a larger problem that is worth addressing in a principled manner has formed somewhat recently - I suspect in the aftermath of modules taking the first principled step to improve integrity, even though it wasn't yet called that back then.

All in all, I think it's to Java's immense credit that the ecosystem recognizes these issues and takes careful steps to rectify them. In this case, by making you avoid or otherwise green-light the mutation of final fields through reflection.

And that's it for today on the Inside Java Newscast. Have a great time, I'll see you again in two weeks. So long...

Watch the video.

Q&A About My Work At Oracle's Java Platform Group

Nicolai Parlog — Mon, 10 Nov 2025 00:00:00 GMT

Answers to the remaining questions that didn't fit into Inside Java Newscast #100

To celebrate the 100th episode of the Inside Java Newscast, I answered your questions about the show and the team behind it. Not all answers made it into the jubilee episode and so here are the remaining ones:

Inside Java Newscast #100, with the first half of the questions - in case you haven't watched it:

Embedded video.

Watch the video.

Try the New Valhalla EA Build - Inside Java Newscast #100

Nicolai Parlog — Thu, 06 Nov 2025 00:00:00 GMT

JEP 401, Value Classes and Objects, has recently re-entered "candidate" status and is getting ready to target a release.

One Hundred Episodes Wow! Thank you so much for watching, y'all, I really appreciate that. And we'll celebrate it later when I'll be answering your questions about this show but first, let's talk about Valhalla!

Welcome everyone to Inside Java Newscast number one hundred - sorry, I just had to say it again - where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and last time I asked you how to celebrate the jubilee and the most requested single topic was Valhalla often plus "when" and your wish is my command, so we'll address both today. "We" is me on Valhalla, including the new EA build that was released last week, and then later Brian Goetz himself on the "when" part. After that, it's time to crack open a drink and chat.

Ready? Then let's dive right in.

Reset

So, Valhalla. This is a huge project! OpenJDK dubbed it Java's biggest refactor, and there have been countless talks, articles, videos, and even prototypes about it, so pretty much everybody has an idea what all this is about. But the issue there is that that idea may not fit the project's evolved understanding of the subject matter nor the plan that has formed for rolling out its features piece by piece and I'm worried that lead to expectations that won't be met in the short term or in some parts even in the long term.

So today I want to do a reset. For the next couple of minutes, take everything you know about Project Valhalla and put it aside. The more you know about Valhalla, the more I'm asking you to do this - blank slate. We'll focus on what's right in front of us and then come back to the bigger picture later.

So what is right in front of us? JDK Enhancement Proposal 401 and the Valhalla early-access build that was released last week.

JEP 401 - Identity

JEP 401 takes on one of Java's core beliefs: "everything is an object". Or rather "everything has identity", because up to now both statements meant the same. What do I mean by that?

Primitives aside, every thing in Java is an instance of a class, and every such instance has an identity that sets it apart from every other instance in the system, even if it is of the same type and represents the same value. The classic example is that if you create two new Integer(5), then these clearly represent the same value (5) but are still not the same thing. And Java recognizes this by having a call to equals return true whereas the comparison with two equal signs, also called identity comparison, is false.

Identity comes with a few nice features. One of them is mutability - only if an instance has identity, does the concept of mutating it even make sense. Because if all you have to identify an instance is its value, then changing the value makes it a different instance. But that's not what we want when we mutate an object.

Say you have a User instance that is referenced by a local variable, a field somewhere, as well as a list that it was put in. If you change the user's name, you naturally expect that change to be visible to code that uses either the local variable, the field, or the list to take a look at the user. Just saying that out loud feels kinda stupid - what else could happen? Well, if the User instance didn't have identity, then all users with the same values, let's assume that's just the name, so all users with the same name look the same. You change one, then what? Now the variable and the field reference users with different names or do somehow all users with the same old name get updated even if having the same name was a coincidence?

So identity allows for mutability and the way the runtime manages that is through unique memory locations and references to them. That, too, is very natural to us. There is one User instance somewhere and the variable, field, and list in the example just reference it, so when one of them mutates it, there is only one memory location to update and all references to it see the new value.

Other data that are connected to identity are the identity hash code (probably not too surprising), monitor lock status, and information the garbage collector needs to track objects, all of which are stored in 8 to 16 bytes that precede each instance's actual data - this is called the object header.

But all that doesn't come for free. That object header is not something that the application logic cares about, so from its/our perspective that's overhead and makes the memory less densely populated with the data we actually care about. And that instances are always connected by references makes the memory... hilly? Whatever the opposite of "flat" is. So, for example, an ArrayList<Integer> is not actually backed by an array containing numbers, it's backed by an array of references that point all over the heap to the Integer instances that wrap the actual numbers. This leads to more cache misses, more memory loads, and an overall worse performance - depending on use case, considerably so.

But identity is not just a performance hazard:

It also means that every object is by default mutable and we need to do extra work to make it immutable.
We can use synchronized on every object even though we probably shouldn't.
And being able to somehow distinguish two things that are supposed to be the same, say two LocalDate instances representing the same day, can lead to bugs, for example through a surprisingly failing == comparison.

So identity comes with a bunch of features and drawbacks. The critical observation is that the features are often not needed. There is no domain-specific reason why two Integer(5)s or two LocalDates for the same day should ever be distinguished. And that holds for a lot of the classes we create, too, particularly if you're programming in a more functional or data-oriented manner. I'd go out on a limb and claim that most classes that only have final fields, don't actually want to have identity. And this is where JEP 401 places its lever.

JEP 401 - Values

The syntax change JEP 401 proposes is laughably small, blink and you'll miss it: It would allow us to place the contextual keyword value in front of class or record, which means instances of those classes have no identity. And that's it. That's all of it. From that semantic (not performance-driven) semantic decision to give up identity for a class' instances follows everything else - and that's quite a lot. Too much, in fact, to discuss it all here, so I'll just touch on a few essential points. As always, JEP 401 is excellently written, so I strongly recommend to give it a read if you're interested in this topic.

So let's go over a few details of the proposal:

We get more nuanced nomenclature: An instance of a value class is called a value object and an instance of a "regular" class is now called an identity object.
That aside, value classes are mostly like identity classes: they extend Object and inherit its methods, can have fields and their own methods, can themselves be abstract and implement interfaces, and so forth. We'll of course focus on the differences but don't let that distract you: They're still a whole lot like regular classes, including the mental model of references.
One of the differences is that a value class as well as all of its fields are implicitly final, making it shallowly immutable. Of course if a final field references a mutable data structure like a hash set, that set does not magically become immutable, too - hence "shallowly".
Since value objects don't have identity, the comparison with two equal signs can't compare identity (duh) and so it will compare all field values. Still, this should not be the default comparison mechanism - value classes can have a meaningful equals implementation that doesn't rely on field-wise equality and other code should default to calling that to figure whether two instances are equal.
Other identity-sensitive operations won't work. For example, synchronizing on a value object will lead to an error - at compile time if possible, otherwise at run time.
Lastly for now, around 30 JDK classes turn into value classes, among them the primitive wrappers, Optional, and a bunch of java.time classes. Unfortunately, String could not come along for the ride - its identity-sensitive operations are used too frequently in existing code to make that change.

Of course JEP 401 explores these topics in more depth and also goes into safe construction, migration, and finally run-time optimizations. I'll let Brian speak to the latter but before I hand it over to him, let me point you to jdk.java.net/valhalla where you'll find the latest Project Valhalla early-access build, which demonstrates everything we just discussed as well some of the optimizations Brian will lay out. I can only recommend you give it a try. If you do so, note that you need --enable-preview to observe any of the changes. Ok, time to let Brian Goetz, Java Language Architect and lead of Project Valhalla, get a word in on performance as well as on the infamous question "Valhalla, when?"

Remainder

Neither Brian's segment nor the Q&A was scripted, so you'll have to watch the video. Here's the full chapter list:

0:00 Intro
0:52 Reset
1:46 Identity
5:48 JEP 401
8:50 Valhalla, when?
9:19 Present Optimization
11:01 Future Optimizations
12:09 IJN Q&A
24:29 The Java DevRel Team at Oracle
27:10 Outro

Watch the video.

Consistent Behavior of new File("")

Nicolai Parlog — Mon, 03 Nov 2025 00:00:00 GMT

Prior to this change, a new File("") behaved differently, depending on whether it was queried as a relative or absolute file

Inconsistencies of 'new File("")'

On JDK 24 and earlier, the behavior of a File instance created from the empty string was inconsistent. Queried for information, it appeared to be non-existent:

var file = new File("");
// print "false" on JDK 24
IO.println(file.exists());
IO.println(file.isDirectory());

Similarly, methods like canRead returned false and length, lastModified, etc. returned 0.

When transformed to an instance representing the absolute path, the behavior changed, though:

var file = new File("").getAbsoluteFile();
// print "true"
IO.println(file.exists());
IO.println(file.isDirectory());

The reason is that new File("").getAbsoluteFile() maps to the current user directory and the File API behaves accordingly. Since new File("") and new File("").getAbsoluteFile() should represent the same file system entry, this inconsistency is jarring and can be surprising.

The newer API in java.nio.file avoids this issue and treats both Path.of("") and Path.of("").toAbsolutePath() as the current user directory. For example:

var path = Path.of("");
// print "true"
IO.println(Files.exists(path));
IO.println(Files.isDirectory(path));

path = path.toAbsolutePath();
// print "true"
IO.println(Files.exists(path));
IO.println(Files.isDirectory(path));

Change in JDK 25

JDK 25 fixed this long-standing inconsistency and new File("") now properly represents the current user directory:

var file = new File("");
// print "true" on JDK 25
IO.println(file.exists());
IO.println(file.isDirectory());

The Javadoc for File was updated to spell out the intended behavior:

Accessing a file with the empty abstract pathname is equivalent to accessing the current user directory.

For more details, check JDK-8024695.

Migration

Code that relies on the old behavior is often found in unit tests (e.g. to intentionally create non-existent files with new File("")) or where user input is mapped to file system entries (e.g. to treat "no user entry" and "invalid user entry" the same: as an absent file). Here it may show itself through misbehavior around file-related arguments or configuration.

While fixing such code should be straightforward, identifying it may not be - a thorough test suite helps. For dependencies and tools, the recommendation is to rely on their tests and statements regarding JDK 25 compatibility. Only they can fix potential issues as there is no way to restore the inconsistent behavior of JDK 24 and earlier.

Three G1 Improvements - Inside Java Newscast #99

Nicolai Parlog — Thu, 23 Oct 2025 00:00:00 GMT

Java's (almost) default garbage collector G1 is undergoing even more improvements

Vroom, vroom, trees! That was my segue from the thumbnail to the rest of the episode. How did I do?

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about a triple of G1 improvements that will make your applications simpler to manage and faster to execute. We'll go from already integrated to barely proposed and top it off with a little ZGC update. But first a little garbage collection primer - skip to this time stamp if you don't need one.

Ready? Then let's dive right in.

Garbage Collection Primer

The ideal garbage collector requires neither extra memory nor CPU-time and never pauses the application, leading to maximal throughput and optimal latency. Funnily enough, such a collector even exists: epsilon GC. The only downside is that it never frees memory and the application just crashes if it runs out. So probably better used for benchmarking than in production.

All GCs that don't crash your application need to make trade-offs, most notably between footprint, throughput, and latency. Parallel GC sits on the throughput end of thing - it does almost all of its work during pause times, which can make them very long (and thus latency very bad) but reduces footprint to a minimum and leads to great throughput. Serial GC is also throughput-oriented. ZGC on the other hand sits on the other end of the spectrum. It does much of its work concurrently with the application, which requires extra memory and CPU time but leads to guaranteed ultra-low pause times even on massive heaps. G1 sits in the middle of this spectrum and by doing some work concurrently but the rest during pauses, it compromises between footprint, latency, and throughput, which makes it the default GC in most environments - more on that later.

G1 is a so-called regional garbage collector, meaning it divides the heap into regions and marks each as containing either young or old objects. That allows for a flexible ratio of the two generations that can align with each application's needs. The separation into regions also brings us to the first G1 improvement.

Simpler Write Barriers for G1

When moving objects from one region to another, references to them must be updated. But G1 doesn't want to scan the whole heap for references to a moved object (because that would take too long) so instead it tracks cross-region references in a so-called card table. To keep that data structure up to date, G1 and the just-in-time compiler inject code fragments into writes to the heap - this is called a write barrier.

That means that when code that runs as part of your application, be it your code, your dependencies' or the JDK's, updates a non-primitive field or array, it ends up executing the write barrier, which means they run in application threads. At the same time, to keep the table performant, G1 is optimizing it in the background, which leads to contention and synchronization with these application threads. As you can imagine, orchestrating all this is also quite complex and that complexity is directly reflected in the write barriers, which can make them rather slow.

And this is where JEP 522 enters the picture. It introduces a second card table so that application threads can work with one and the G1 optimizer threads with another plus a mechanism for swapping and reconciling them. That reduces contention and the need for synchronization and also simplifies the write barriers. According to the JEP, that simplification alone leads to throughput gains of up to 5% across the board with applications that heavily modify object-reference fields further benefiting from the reduced contention and seeing improvements of up to 15%. Pause times and thus latencies decrease slightly.

JEP 522 is already integrated into JDK 26 and available in the early access builds - links to that as well as to everything else I mention in this episode are in the description.

Make G1 The True Default

G1 is often described as Java's default garbage collector, but that's not actually true. You see, Java is just a standard and its governing body, the JCP, doesn't recognize the concept of a default garbage collector... No! Begone, evil spirit. Begone!

What I meant to say is that, if no command-line option chooses a specific GC, the runtime will often but not always default to G1. On single-CPU machines with less than a bit under 2 gigs of memory it picks Serial GC instead because in that kind of environment, it used to have significant advantages in throughput and footprint. Note the past tense, though. Over the last couple of releases, G1's footprint has come down and recent work, particularly the simpler write barriers we just discussed, has brought its throughput close to Serial GC's in these constrained environments. So the two collectors are now competitive on these two metrics, but G1's maximum latencies have always been better than Serial's.

So JEP 523 proposes to always default to G1, regardless of environment, which will improve maximum latencies in many situations where Serial GC used to be selected and will also make it easier to understand and reason about the JVM’s behavior. It also reduces the number of topics, on which people like me can "well actually" you, which is somewhat annoying to me personally but probably a plus for the wider community.

And don't worry if Serial GC performs better than G1 in your environment. There are no plans to remove it and you can still select it explicitly with a simple -XX:+UseSerialGC. JEP 523 is not yet proposed to target a release.

Automatic Heap Sizing

The minimum and maximum heap size can be configured with the options -Xms and -Xmx, respectively. Determining the best values isn't easy, though:

the application's memory requirements can change throughout its run time
the JVM's own variable memory requirements need to be factored in
other applications may require memory
and so does the operating system, for example to populate file caches

Take all this together and it becomes obvious that determining heap size is no simple task.

Can't someone else do it? The garbage man can!

Exactly - let the garbage collector determine its own minimum and maximum heap size! And there's a JEP draft that proposes just that for G1. It would automatically and dynamically size its heap anywhere between 4MB or -Xms, whatever is higher, and close to all of the available memory or -Xmx, whatever is lower. So if you know your exact heap size needs, set -Xms and -Xmx to exactly that, but otherwise you're encouraged to omit both values and let G1 choose. It will do so by considering a multitude of factors:

the total memory
whether compressed oops are enabled, which limits the heap to 32 gigs
the environment's pressure

Oh shit! The wind tries to take the camera and there's a steep drop right there.

Ok, starting over. It will do so by considering a multitude of factors:

the total memory
whether compressed oops are enabled, which limits the heap to 32 gigs
the environment's memory pressure
the application's allocation rate, with a specific eye on surges
the JVM's internal native memory usage
the GC's CPU overhead
the G1 options GCTimeRatio and G1GCIntensity, the latter of which is new
and probably more

To balance all these factors, G1 will shrink and expand the heap as needed. If you're interested in more details on how it does that, check out the JEP. But keep in mind that it's still a draft, which means it's very early days for this feature and lots may still change.

Also, ZGC

This video is all about G1, but it would be remiss of me not to at least mention that there's another JEP draft that proposes automatic heap sizing for ZGC, too. Love it! Taken all together, we're looking at a future where a big chunk of applications have optimal GC behavior with zero flags and another big chunk need to do nothing else but select ZGC to get the same. What a time to be alive.

And that's it for today on the Inside Java Newscast. I'll see you again in two weeks for the one-hundredth episode, although I'm not yet sure how to celebrate that. If you have any ideas, I'd love to hear them. Either way, see you then - so long ...

Watch the video.

All API Additions From Java 21 to 25

Nicolai Parlog — Tue, 09 Sep 2025 00:00:00 GMT

Learn about all API additions between Java 21 and Java 25: scoped values, stream gatherers, class-file API, foreign function and memory API, Javadoc additions, and preview features.

As is, this video's script is way too confusing to work in written form and I am way too busy (read: "lazy") to patch it up until it does, so I'm afraid, you'll have to watch the video. Here are time-stamped links to each chapter together with all follow-up sources:

Intro

Smaller Additions

CLDR Update: Quality Heads-up
New APIs in Javadoc

Scoped Values

Stream Gatherers

Class-File API

Foreign Function and Memory API

JEP 454

Javadoc Improvements

Preview Features

Next Up

If you haven't watched it yet, also check out this video on how to update to Java 25:

Embedded video.

Watch the video.

Structured Concurrency in Action

Nicolai Parlog — Wed, 03 Sep 2025 00:00:00 GMT

A deep-dive into the structured concurrency API as it is currently proposed

In Java 25, the structured concurrency API saw its fifth preview with considerable changes over previous iterations. Java 26 made only small tweaks and with chances being good that it will finalize without a further overhaul, let's put it into action and explore how to:

structure concurrent code
process and propagate errors and cancellation
observe thread relationships
refactor from a reactive approach

After this presentation you'll be ready to put the structured concurrency API into action in your project.

Upgrading From Java 21 To 25: All You Need To Know

Nicolai Parlog — Sun, 24 Aug 2025 00:00:00 GMT

Updating from Java 21 to 25 is a smooth experience. Unless you're working on an unlucky project that collected all the little details that change: Whether it's annotation processing, null checks, file operations or the removal of old technologies, Peter collects them all.

Intro

Default Annotation Processing

Quality Heads-up

Final Record Pattern Variables

JDK-8317300

Security Property "include"

Quality Heads-up

Null Checks in Inner Class Constructors

Quality Heads-up

Unsafe Memory Access

memory access warnings: JEP 498
memory access deprecation: JEP 471
shouldBeInitialized, ensureClassInitialized: JDK-8316160
park, unpark, ...Fence: JDK-8315938

Native Access

Security Manager

Quality Heads-up
JEP 486
changes to Subject API: Quality Heads-up

File System Operations on Windows

deletion and trailing spaces: Quality Heads-up
\\?\C:\ style paths: JDK-8287843
trailing space in paths: JDK-8354450
deleting read-only files: JDK-8355954

Unicode Updates and COMPAT Removal

CLDR by default: JEP 252
COMPAT removal: Quality Heads-up & JDK-8174269
CLDR updates: Quality Heads-up
CLDR v44: JDK-8306116 & Unicode CLDR 44

Intermission

Removals

32bit: JEP 503
GTK2: JDK-8329471 & JEP 283
time zones: JDK-8340477
command line options:
- -XX:[+-]RegisterFinalizersAtInit: JDK-8320335 & JDK-8320522
- -XX:+UseEmptySlotsInSupers: JDK-8330607 & JDK-8330699
- -Xnoagent: JDK-8312072 & JDK-8312150
- -t, -tm, -Xfuture, -checksource, -cs, and -noasyncgc: JDK-8339918
- jdeps -profile, -p: JDK-8310460
methods on Thread and ThreadGroup: JDK-8320532 & JDK-8320786
system property jdk.reflect.useDirectMethodHandle: JDK-8305104
module jdk.random: JDK-8330005

Deprecations for Removal

various command line flags: JDK-8227229, JDK-8286851, JDK-8350754
modules: JDK-8311530 & JDK-8308398

Separate Metaspace and GC Printing

Quality Heads-up

Remote Debugging with jstat and jhsdb

Quality Heads-up

Outro

Next Up

If you haven't watched it yet, also check out this video on all the API additions in Java 25:

Embedded video.

Watch the video.

Java Architects Answer Your Questions - Inside Java Newscast #97

Nicolai Parlog — Thu, 14 Aug 2025 00:00:00 GMT

You asked questions, Java architects have the answers - from switch and if expressions to record identity, from optimal training runs to differentiable programming, and more

Links to the Questions (and Subsequent Answers)

Why can't you return from a switch expression?

When you're doing a training run, what should you consider to get the best out of Leyden?

With the introduction of value classes do you ever see a reason for an identity-based record?

Adding safe navigation after introducing null-restricted and nullable types?

Lightning round:

Extreme lightning round with links elsewhere:

I'd be curious to know if there have been any discussions around adding 'if' expressions to the language.

There are many examples of some older classes in Java, like Date, Vector, Hashtable, where you can use them but it's heavily suggested to not use them. Why not simply deprecate and remove those classes?

Would Project Babylon and the Java ecosystem overall support differentiable programming?

Is there any chance of Java officially targeting web assembly so that it can run “natively” and optimized in browsers?

Any spoilers ahead for Project AmberProject Amber?

Watch the video.

HTTP/3 in Java - Inside Java Newscast #96

Nicolai Parlog — Thu, 31 Jul 2025 00:00:00 GMT

JEP 517 proposes to update Java's HTTP Client (introduced in Java 11) to be compatible with HTTP/3

Yes, you've seen a similar thumbnail just two weeks ago. Thanks for clicking nonetheless, this is indeed a different video. We just ran out of ideas and that one seemed to do well. Could've been worse.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about JDK Enhancement Proposal 517: HTTP/3 for the HTTP client API that was introduced in Java 11. We'll also have an AMA (ATAA) soon, where you get to ask your questions and we make the OpenJDK folks answer them, more on that at the end of the video.

Ready? Then let's dive right in.

HTTP/3

In 2022, HTTP/3 was standardized and it is intended to be a successor to HTTP/2. But instead of TCP, it uses the UDP-based QUIC as transport-layer protocol, which, together with other changes, promises lower latency, less network congestion, and more reliable transport.

HTTP/3 is supported by every modern browser and deployed to a little over one third of all websites. So high time that Java gets on board, which is what JEP 517 intends to do. It is not currently targeted to any release, but I would be surprised if we didn't see it in Java in 2026.

At its heart, this change is very simple: The HTTP client will be updated to allow it to send and receive HTTP/3 requests and responses. The central API change is super small, just the new value HTTP_3 for the enum HttpClient.Version. You pass the value to the builder method version when building an HTTP client or request, which you then use as you normally would.

var client = HttpClient
	.newBuilder()
	.version(HttpClient.Version.HTTP_3)
	.build();

var request = HttpRequest
	.newBuilder(
		URI.create("https://openjdk.org/"))
	.version(HttpClient.Version.HTTP_3)
	.GET().build();

var response = client
	.send(request, BodyHandlers.ofString());

Almost everything else happens beneath the surface. What is a bit tricky is how the API determines what HTTP version ends up being used, so lets look at that next.

Negotiating the HTTP Version

The thing is that HTTP/1.1 and 2 use the same transport-layer protocol (TCP) and so a connection can be initiated and then upgraded. But since HTTP/3 ultimately uses UDP, you cannot upgrade a TCP-based connection to it. And because you don't generally know for any given server, what HTTP version it supports, you may have to make multiple requests to figure things out and there are different strategies you can employ:

(To save ourselves some time and sanity, I will only mention HTTP/2 and implicitly include 1.1 in that.)

You can start with an HTTP/2 request and if the response indicates that HTTP/3 is available, you switch to that.
Or you can start with an HTTP/3 request and, if you don't receive a response in time, repeat it with HTTP/2.
Or, if you don't receive a response in time, you fail.
And finally, you can send the first request twice with HTTP/2 and 3 and then reply with the version that got the first response.

Luckily you don't need to do any of that. Java's HTTP client can do this for you and you can select any of these four strategies with the right combination of arguments to the aforementioned version methods as well as to the new setOption method on the client builder. I will spare you the exact details of what does what because, let's face it, by the time this feature shows up in a GA release, let alone in our code bases, we'll all have forgotten these details two times over. The JEP has you covered.

Potential Improvements

Instead, I want to briefly cover a few things that JEP 517 doesn't do:

make HTTP/3 the default - HTTP/2 will remain the preferred version
add configuration options to the HTTP client and request builders to control discovery of the target server
add configuration and tuning options for the HTTP/3 implementation
add new exceptions for HTTP/3-specific errors
provide an API for QUIC
provide a server-side implementation of HTTP/3

Some of that is probably going to get worked on in the future - for now, it's important to get HTTP/3 out the door. And that's all on that topic, now let's talk about ATAA.

Ask The Architects Anything

ATAA of course stands for Ask The Architects Anything and, no, you can't just say it like a normal person - it has to be ATAA. Anyway, next week is the JVM Language Summit and after hitchhiking across the United States all the way from Kansas, Billy will be there to ask the OpenJDK folks your questions. Brian Goetz will be there, and John Rose. Dan Heidinga, Joe Darcy, Paul Sandoz, and many, many more. So whatever question you have on your mind, Billy will find an expert to answer it.

I will pin a comment about that below the video - please reply with your questions there, so I can collect them. Also, if you're curious about other people's questions and the architects' answers, go watch any of these videos from previous ATAAs.

Beneficial side effect: You won't ask a question that was already answered, because I will ruthlessly cull those. Billy will see you in two weeks and then we have something special for you in late August. So long...

Watch the video.

Java Gets a JSON API - Inside Java Newscast #95

Nicolai Parlog — Thu, 17 Jul 2025 00:00:00 GMT

Java considers itself a "batteries included" language and given JSON's ubiquity as a data exchange format, that means Java needs a JSON API.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and tonight we're gonna talk about the JDK's path towards a JSON API. This is based on an email that Paul Sandoz, probably best known for being the lead of Project Babylon (woo), sent to the core-libs-dev mailing list back in May. That means, we don't even have a JEP draft, yet, so all of this is very early and this episode is more about the big picture than about details.

Ready? Then let's dive right in.

(Boy, am I happy this take worked.)

Start with Why

Let's start with why - why does the JDK need a JSON API? It's decidedly not because there's a lack of JSON libraries in the ecosystem. Not only are there plenty, many of them are doing a really great job!

No, the motivation comes from the overlap of two facts:

JSON has become a universal and omnipresent data interchange format and
The JDK has a "batteries included" philosophy, which aims to provide all building blocks needed to write basic programs

Taken together, the JDK wants developers to be able to write basic programs without having to rely on third-party dependencies and nowadays that means it needs to be able to effortlessly handle JSON.

But that also means that this API is not meant to once and for all solve the JSON problem, to cover every use case, and in the process make all those existing project superfluous. No, it aims to sit on the other end of the spectrum: be simple to use for parsing, traversing, and generating conformant JSON documents and leave more advanced features like data binding or path-based traversal to third-party libraries. Performance should be "good enough" but will be less important than simplicity.

Look and Feel

JSON can be described by what's called a "railroad diagram", which shows how to construct it via subtyping and composition. Or sums and products. Or algebraic data types. Or data-oriented programming. (Yes, yes, it's not all the same, but here it's close enough.)

So we need to model a "value" with possible expressions like "array", "object", and "number". And after everything I've learned and said about data-oriented programming in recent years I would expect this to be a sealed interface with record implementations, but annoyingly it's neither. While that approach is a perfect fit, the lack of encapsulation makes internal evolution behind a stable API tricky. In many situations, that's no big issue but for a public JDK API it does matter. So, to my dismay, the idea is to use interfaces with hidden implementations: At the top, there would be JsonValue, extended by JsonArray, JsonObject, JsonString, JsonNumber, and so forth, each with an accessor method like values(), members(), value(), etc.

interface JsonValue { }

interface JsonArray extends JsonValue {
	List<JsonValue> values();
}

interface JsonObject extends JsonValue {
	Map<String, JsonValue> members();
}

interface JsonString extends JsonValue {
	String value();
}

interface JsonNumber extends JsonValue {
	Number toNumber();
}

To get instances of these classes you could call a parse method with a JSON string that then returns a JsonValue. Alternatively, static factory methods can create them from the Java type they contain, for example a JsonArray from a List, a JsonObject from a Map, or a JsonString from a, you guessed it, String.

JsonValue doc = Json.parse("""
	{
		"name": "John Doe",
		"age": 30
	}
	""");
/* {+} */
JsonObject obj = JsonObject.of(Map.of(
	"name", JsonString.of("John Doe"),
	"age", JsonNumber.of(30)
));

Either way, once you have JSON values in hand, the only two mechanisms to interact with them are type checks and accessors, both presumably as part of pattern matching. Paul gives an example for how this API can be used to safely traverse a JSON document. Given a simple JSON object, we may want to ask whether it has "name" and "age" properties and whether the age fits into an int and, if so, extract said properties into String name and int age variables. Because the JSON types are interfaces and not records and maps and lists don't interact with patterns, yet, the condition that verifies all that is a bit bulky at the moment, but once we get deconstruction patterns, it shrinks down to:

var doc = Json.parse(inputString);
if (doc instanceof JsonObject(var members)
    && members.get("name")
		instanceof JsonString(String name)
    && members.get("age")
		instanceof JsonNumber(int age)) {


	// use "name" and "age" 😁

}

If the Json.parse(document) instanceof JsonObject(var members) and members.get("name") instanceof JsonString(var name) and members.get("age") instanceof JsonNumber(int age), then we're happy and can use name and age.

Paul writes:

So, over time, as more pattern matching features are introduced we anticipate improved use of the API. This is a primary reason why the API is so minimal. Convenience methods we add today, such as a method that accesses a JSON object component as, say, a JSON string or throws an exception, will become redundant in the future.

An example of that can be seen in the way the API handles numbers. The JSON specification makes no explicit distinction between integral and decimal numbers, nor specifies limits on the size of those numbers, which means Java code does not generally know what Java type best fits a JSON number's string representation. This API deals with that by making JsonNumber parse to the Java Number subtype that best fits the string and then letting the user apply pattern matching to limit what types she's willing to process.

That indeed makes this API very minimal to the point where it hardly has any API. And that doesn't come without criticism.

(Apparently, night's over.)

Current State and Next Steps

The reason why Paul wrote this email is that Project Babylon developed a variant of this API for its internal experiments - unrelated to JSON but, yeah, it is omnipresent. So they've been working with this for a while and Paul describes it as a "pleasure", they "were able to quickly write code to ingest and convert" and "the out-of-box experience has so far been positive".

The prototype implementation is located in the JDK sandbox repository under the json branch, which I link in the description together with the just as prototypical Javadoc. It passes all applicable conformance tests of the unofficial but well-established JSONTestSuite and performance is good when compared to other JSON implementations even though not a lot of optimizations have taken place yet.

So all good? JDK Enhancement Proposal, when? Not so fast! This API has only been exposed to a few real-life use cases and as I alluded to a minute ago, not everybody is happy with the very minimal, very pattern-matching-heavy design that makes some common tasks more cumbersome than a simple method would. That seems particularly true when it comes to behavior like "try to access this as an instance of that type or throw a helpful exception if it doesn't work", which is necessary to handle messy real-world use cases. And it's not like Java's future pattern-matching features are all already settled, so that adds some uncertainty to this design, too. I think it's safe to say that this will brew a little longer before it turns into a JEP, which might be a new one or an update of JEP 198, by the way. But once that happens, we'll of course cover it here.

I'll see you then or, better yet, in two weeks. So long...

(Time to have breakfast, I guess.)

Watch the video.

Java 25 is ALSO no LTS Version - Inside Java Newscast #94

Nicolai Parlog — Thu, 03 Jul 2025 00:00:00 GMT

Java 25, much like Java 21, will be described as a "long-term-support version" despite the fact that that's categorically wrong.

We've been here before - in this kitchen but also on this topic. Two years ago, when Java 21 was about to be released, I made a video titled "Java 21 is no LTS Version", which explained how maintenance and support work in the Java ecosystem and why the statement "Java 21 is a long-term-support version" is wrong and should instead be be "JDK 21 is a version, for which many vendors offer long-term support". It was generally well-received but there was a subset of the audience, some of them among the more widely-known and supposedly better-informed folks in the community, who pushed back against some aspect or other. Back then I wrote a lengthy reply but then I decided I didn't want to start any drama and put it in the drawer. Now, two years later, with stagnant Newscast viewership numbers, I need that dra...

Now, two years later, another Java version is about to be mislabeled and I think we could all do with a refresher. One that sticks to the most salient points and learns from / addresses some of the criticism my first video received - chief among them why this distinction matters, why it is important to talk about this correctly. This video will be self-contained, but if you want to learn more about OpenJDK or the details of how JDK maintenance and support are provided, check out these two Newscasts. Now, time for some dra...

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about Java 25 and why it's no long-term support version and about JDK 25 and why it's a version with a lot of long-term support - and we'll start with why the distinction matters. Ready? Then let's dive right in!

Why it Matters

The term support comes up a lot in the Java ecosystem, but not everybody who uses it means the same thing. My understanding aligns with the definition given in the influential 2018 Java Champions article Java Is Still Free:

Support means a commitment to fix bugs, and it requires staff to answer users’ problems, which costs money.

I don't like to talk about the competition in detail, so forgive me if I keep this a little vague, but say you have some vendor's JDK 11, 17, 21, or soon 25 running on your premise and now something ugly happens that you need them to look at ASAP to fix it - you need support. With the faulty assumption that these Java releases "are LTS version", that should be easy, right? Spoiler: It's not.

Some JDKs come without any support, there's never anyone who is obliged to help you out - this is true for a number of free JDK distributions, for example Oracle's builds of OpenJDK that you can get at openjdk.org. Then there are a bunch of JDKs that you can use for free but to get support, you need to enter some kind of contract. That's true for Oracle JDK, for example, that you can get from oracle.com/java. You may also get support if you run a vendor's JDK on their cloud infrastructure but not if you run it on your premise. And finally, some JDKs are fully commercial, only available through a contract that then also includes support.

But also, beyond "LTS versions" 11, 17, 21, and 25, if you've been using JDKs 13 or 15, you could've gotten 2-3 years support for that from a vendor. Just one though. How dare they, these were no "LTS versions"! Can they just do that?

And what's up with 2-3 years, can anybody just pick how long they maintain these versions? Apparently, since different vendors offer different support timelines, even for 11, 17, and 21. How's that all over the map?

Then, if certain Java versions are "LTS", how come the feature selection doesn't align with that? Maybe those versions should finalize ongoing previews, yet JDK 25 has five non-final features, 21 had seven, and 17 had three. Or maybe they shouldn't rock the boat, be a stabilization of the previous releases, yet 25 had seven features that showed up for the first time, three in preview, four directly final; 21 had six of those and 17 had five. It's almost as if the people developing Java don't care about LTS!

There's a final point, more abstract and important, why the details matter and I'll get to that at the end of the video. Let's leave this list here with the acknowledgment that none of these considerations and the confusion that comes from misunderstanding LTS concern everyday programming. You can be a great Java dev and not think about any of this ever. But if you want to understand not just the technology but how it evolves, how the ecosystem works, even just which JDK distribution to pick, this is important. And it's not very complicated either, you just have to accept that it's not dead simple and read, write, listen, and speak accordingly. So let's do that!

This vs That

First a few quick disambiguations, and we'll start with Java 25 vs JDK 25: Java 25 isn't really anything, except likely a shortcut for Java Platform, Standard Edition 25. But that's neither a binary nor code. It's a set of specifications that define the behavior of a language, its API, a virtual machine, and a few other things. The thing that gets new commits is the Java Development Kit, the JDK, in this situation specifically JDK 25. It's the reference implementation of the standard and OpenJDK is developing it. But they don't ship a binary! (As an aside: that means nobody is "running OpenJDK".) This is where vendors come in.

So, up next OpenJDK vs vendors: OpenJDK is the place where people collaborate on that reference implementation and related projects. It has bylaws, development practices, a website, mailing lists, just so many mailing lists - more on all that in this video. For many people in this community, their work on Java is a full-time job and they get paid for it by companies that do that out of the goodness of their heart. Nah, I'm just kidding, they earn money with Java and as long as they do and are smart about it, they will keep pushing Java forward, which is a win-win in my book. And one way how they earn money is to build a binary that matches the standard, usually from the OpenJDK code base aaaand (thank you) offer support for it.

Remember that support costs money? Specifically, your money if you choose to pay for it. "But wait", some of you are typing in the comments, "I use a free distribution with support and don't pay anything". Eh... you get timely updates for all important issues but you can't rely on getting help if you have a problem, so as per the earlier definition, you don't get support. The Java Champions article calls this updates:

Updates refer to the code patches (including security) that have gone into OpenJDK and Oracle JDK.

Personally, I prefer the term maintenance but we mean the same thing. And, by the way, this is more than enough for many people and organizations in the Java community - if you get by well with just updates/maintenance and without paying anybody for support, that's great and totally cool with me. So that was the third distinction - support vs updates or maintenance.

Now it's time to put the buildings blocks together and resolve the earlier misunderstandings.

Long-Term Support

I didn't mention it before, but it's the Java Community Process that develops the standard technical specifications for Java and it's OpenJDK that, in tandem with the JCP, develops the reference implementation for it. Then the vendors ship binaries and decide which versions to offer maintenance and/or support for. They usually do end up offering that for similar time frames for the same versions, namely 11, 17, 21, and 25. The "21 is no LTS"-video explains why that's the case and how the whole process of developing, upstreaming, and distributing patches works in detail. But that convergence, while not really coincidental, is still decentralized and happens on the vendor level. OpenJDK doesn't plan for it and neither does the JCP.

So it categorically can neither be Java nor "JDK", in general, that gets LTS, only specific distributions like Oracle JDK 25, for example.

And that quickly resolves all confusion:

What level of maintenance or support you can expect from the JDK you use doesn't depend on which Java version "is LTS" but solely depends on the vendor who gave it to you. That includes for which versions and for how long.
And it doesn't just seem like the people developing Java don't care about LTS, for their work in OpenJDK that's absolutely true. Java's feature development is unencumbered by support concerns.

The Larger Goal

One common response I get to my insistence on phrasing this right is that that's too complex for the average Java programmer or that it would confuse business people. Leaving the blatant elitism aside, if you look at the comments my last video got, it's clear that the confusion does not come from the facts I explain but from the contradiction between those facts and people's perception. It's not the reality that's confusing, it's "Java 21 or 25 is an LTS version" because not only is that false, as we've just discussed, it's apparent simplicity is also a mirage that falls apart immediately when you try to apply it to the world around you.

And here we come to my final point. Let's not forget that not everybody is a friend of the Java community and ecosystem. There are lots of people and organizations, particularly outside of it, that would love to make a few quick bucks off of it or even see it fail. And an effective way to do that is to drive a wedge in between the facts and people's perception of them and then use that as a lever to pry the community apart. A great example for that happened in 2017 - I retell it in a pinned comment. We defend ourselves against tactics like that not by insisting that the perception is real but by ensuring that the perception matches reality. Namely: Java 25 is no LTS version. But basically every JDK 25 distribution will get updates or even support for a long time.

Easy, right? If not, ask away in the comments. I'll see you down there or otherwise in two weeks. So long...

Watch the video.

Java 25 Encodes PEM - Inside Java Newscast #93

Nicolai Parlog — Thu, 19 Jun 2025 00:00:00 GMT

Java 25 previews an API that transforms PEM (Privacy-Enhanced Mail) texts into cryptographic objects like public or private keys, certificates, and certification lists and vice versa.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna take a closer look at an API that has its first preview in Java 25: encoding and decoding PEM texts. What's a PEM, why is this important, and how do you use that API? We'll get to all that. Ready? Then let's dive right in!

PEM Texts

PEM is specified by RFC 7468. It's a textual representation of cryptographic objects like private and public keys, certificates, and certificate revocation lists. You've very likely already used PEM texts, for example when you uploaded SSH or PGP keys to GitHub or artifact repositories. They have a header and footer that each start with five dashes, the word "BEGIN" or "END", respectively, a textual description of what's being encoded, for example "PUBLIC KEY", followed by another five dashes. The text's body is the cryptographic object's Base64-encoded binary representation.

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj
0DAQcDQgAEi/kRGOL7wCPTN4KJ
2ppeSt5UYB6ucPjjuKDtFTXbgu
OIFDdZ65O/8HTUqS/sVzRF+dg7
H3/tkQ/36KdtuADbwQ==
-----END PUBLIC KEY-----

PEM is short for Privacy Enhanced Mail but as you can tell by where you've seen them, the format has left that context behind long ago. Nowadays it's used by a wide range of services:

development platforms like GitHub
certificate authorities
cryptographic libraries such as OpenSSL
security-sensitive applications such as OpenSSH
hardware authentication devices such as YubiKeys
and, most importantly, in your applications to send and receive cryptographic objects via user interfaces, over the network, to and from storage devices, etc.

So, clearly, a general-purpose, batteries-included development platform like Java should allow encoding and decoding cryptographic objects as PEM texts. And it does that already today but the process is manual and a bit tricky and the Java Cryptographic Extensions Survey in April 2022 confirmed the lack of an easy-to-use API as a pain point. So OpenJDK set out to fix this and previews an API in Java 25 that promises just that. Let's take a closer look.

PEM API Basics

As I just mentioned, Java already provides the building blocks for PEM en- and decoding and the most fundamental one of these is the various cryptographic objects' abilities to convert themselves to and from binary data in the DER format, which make up the PEM texts' bodies. Unfortunately, these capabilities are strewn around various unrelated types like KeyPair and X509Certificate without a uniform way to access them.

KeyPair kp = // ...
byte[] encodedPublic =
	kp.getPublic().getEncoded();
byte[] encodedPrivate =
	kp.getPrivate().getEncoded();

X509Certificate cert = // ...
// throws CertificateEncodingException:
byte[] encodedCert = cert.getEncoded();

There's a wide range of design options that can bridge this gap and JDK Enhancement Proposal 470, which introduces this API, goes over a list of alternative designs and their shortcomings that I recommend diving into if this topic is near and dear to you. Here, I'll skip them and focus on the chosen solution:

an empty, sealed interface that all DER-encoding-capable types extend - aptly named DEREncodable
the classes PEMEncoder and PEMDecoder that transform DEREncodable instances to PEM texts and vice versa

The encoder and decoder classes are immutable, reusable, and thread-safe and the basic use of this API is very straightforward:

create an encoder or a decoder with the respective static factory method of()
call PEMEncoder::encode or encodeToString with a DEREncodable instance to get a PEM text as either an ISO-8859-1 byte array or as a string
and then call decode with a PEM text as string or ISO-8859-1-encoded input stream to get a DEREncodable instance back

X509Certificate cert = // ...

PEMEncoder pe = PEMEncoder.of();
String pem = pe.encodeToString(cert);

PEMDecoder pd = PEMDecoder.of();
DEREncodable cert2 = pd.decode(pem);

There are of course a few details to consider that we'll go over now.

`DEREncodable` and `PEMRecord`

First, what types are actually DEREncodable? I could read out the list but that quickly turns into word salad, so you'll unfortunately have to stop making lunch, or folding laundry, or whatever else you're doing while watching Inside Java Newscasts, and glance at the screen for a moment to satisfy your curiosity.

AsymmetricKey (with subtypes for private/public keys for DH, DSA, EC, RSA, etc.)
KeyPair
PKCS8EncodedKeySpec
X509EncodedKeySpec
EncryptedPrivateKeyInfo
X509Certificate
X509CRL
PEMRecord

And while I have you here: I'm curious - what do you do while watching?

The last class on that list, PEMRecord, is new. It captures the PEM texts of cryptographic objects that the JDK doesn't have a type for, such as PKCS#10 certification requests, thus enabling you to process them, as well. PEMRecord is indeed a record with three components:

String type - the header text, like "PRIVATE KEY" for example
String content - the Base64-encoded PEM body
byte[] leadingData - that's any content preceding the PEM header

A decode call will return a PEMRecord if there's no Java platform type to represent the cryptographic object or if you explicitly ask for this type - we'll see how in a few minutes. You may want to do that because it's the only way to access the data that precedes the PEM header.

String pkcs10Text = // ...
PEMDecoder pd = PEMDecoder.of();
DEREncodable pkcs10 = pd
	.decode(pkcs10Text);

if (pkcs10 instanceof
		PEMRecord pem) {
    var der = pem.content();
	var dt = pem.leadingData();
}

Private Keys and Passwords

When handling private keys, you can encrypt and decrypt them by upgrading the encoder and decoder to new instances that use a password. A PEMEncoder that uses a password can only encode private keys, whereas such a PEMDecoder can still decode unencrypted objects, too. When encoding a private key, consider calling encode instead of encodeToString because encode returns a byte array and that gives you more control over its lifecycle.

PrivateKey key = // ...
char[] password = // ...

PEMEncoder pe = PEMEncoder
	.of()
	.withEncryption(password);
byte[] pem = pe.encode(key);

PEMDecoder pd = PEMDecoder
	.of()
	.withEncryption(password);
DEREncodable key2 = pd.decode(
	new ByteArrayInputStream(pem));

If you want to encrypt with non-default parameters, algorithms, or encryption providers, you need to use an instance of EncryptedPrivateKeyInfo. This class already existed before the PEM API and was extended to better interact with it. The idea is to turn an instance of PrivateKey into an instance of EncryptedPrivateKeyInfo with additional information like password, algorithm, etc. and then encode that to a PEM text. Decoding then starts with that text and returns an instance of EncryptedPrivateKeyInfo that can be turned back into a PrivateKey with the correct incantation.

PrivateKey key = // ...

char[] password = // ...
String algo = // ...
AlgorithmParameterSpec params = // ...
Provider provider = // ...

EncryptedPrivateKeyInfo encryptedKey =
	EncryptedPrivateKeyInfo.encryptKey(
		key, password, algo, params, provider);

PEMEncoder pe = PEMEncoder
	.of()

byte[] pem = pe.encode(encryptedKey);

PEMDecoder pd = PEMDecoder.of();
DEREncodable encryptedKey2 = pd.decode(
	new ByteArrayInputStream(pem));
if (encryptedKey2
		instanceof EncryptedPrivateKeyInfo e) {
	PrivateKey key2 = e.getKey(password);
	// ...
}

You can also use a specific cryptographic provider for decoding by again upgrading the decoder to a new instance.

Decoding to Specific Types

The PEMDecoder's decode methods that accept a string or input stream return an instance of DEREncodable. This is intended for the general case where you don't know what cryptographic object the PEM text represents, and you can resolve that with pattern matching: Simply switch over the decoded instance, handle the types you expect, and error-handle the remaining ones.

String pem = // ...

PEMDecoder pd = PEMDecoder.of();
DEREncodable decoded = pd.decode(pem);
/* {+} */
switch (decoded) {
	case PublicKey key -> // ...
	case KeyPair kp -> // ...
	case PEMRecord rec -> // ...
	default ->
		throw new IllegalArgumentException();
}

Alternatively, if you expect a specific subtype of DEREncodable, you can pass that type to an overload of decode and then get back such an instance - or an exception, of course, if the types don't line up. This is also how you can explicitly request a cryptographic object to be decoded to a PEMRecord instance even if the JDK has a specific type for it.

String pem = // ...

PEMDecoder pd = PEMDecoder.of();
PublicKey decodedKey = pd
	.decode(pem, PublicKey.class);
PEMRecord decodedPem = pd
	.decode(pem, PEMRecord.class);

As mentioned, this API is in preview in JDK 25. Since we're now in Ramp-Down Phase 1 and 25 is in feature freeze, everything new is included in the current early access builds, so if PEM texts or any of the other improvements - I went over all of them two weeks ago - are interesting to you, give them a try. And if your experiments pop up something noteworthy, be sure to report it to the mailing list - each JEP lists the corresponding one up top in its header.

I'll see you again in two weeks. So long...

Watch the video.

Java 25 Brings 18 JEPs 😱 Inside Java Newscast #92

Nicolai Parlog — Thu, 05 Jun 2025 00:00:00 GMT

Java 25 will be released on September 16th. Its feature set has been frozen today and it is impressive: 11 finalized features in language, APIs and the runtime plus 7 that are brewing.

JDK 25 is driving me mad! Another release with so, so, so many additions! I'll have to think about how, now that the feature set is frozen, I can stuff all of that into one episode.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna go over everything that JDK 25 brings to Java - and it's a lot! Here's how we're gonna fit all that into the time we have: A bunch of the features come out of a series of previews that I've covered extensively in the past. And I will keep coverage of them short, very short. In fact, this short:

Flexible Constructor Bodies

JDK 25 finalizes the addition of a so-called prologue to constructor bodies before an explicit call to another constructor with this() or super(). The code it contains can do whatever it wants except reference the instance under construction for anything but field assignments. The prologue is great for easier validation, preparation, and sharing of arguments before passing them to another constructor, which comes in particularly handy when writing records as they require constructor chaining.

record Name(String first, String last) {

	// VALIDATION
	Name(String last) {
		if (last.length() == 0)
			throw new IllegalArgumentException();
		this("", last);
	}

	// PREPARATION
	Name(String f, String m, String l) {
		var fullFirst = f + " " + m;
		this(fullFirst, l);
	}

	// SHARING
	// yes, can't coexist with `Name(String last)`
	// it's just an example :)
	Name(String full) {
		var names = full.split(" ");
		this(names[0], names[1]);
	}

}

Intro Part 2

Yeah, that was quick. But I linked JDK enhancement proposals and deeper dive videos in the description that you can check out. Or, if you don't want to trawl older videos, wait for the summer when we'll cover every final feature between Java 21 and 25 in a dedicated video series. But for today, it's just JDK 25 - final and preview, first language, then APIs, then runtime, which has seen a surprising number of pretty cool, last-minute additions. Ready? Then let's dive right in!

Module Import Declarations

With a simple import module $moduleName you get to import the full public API of the named module, which is superior to star imports because it fully imports a coherent API instead of just a random slice of it. Whether they're preferable over the precision and clarity of single-type imports remains a matter of taste, but there are situation where that hardly matters: experiments, demos, scripts, early learning are some of them and here you should probably default to module imports. This feature is final in JDK 25 without change.

Compact Source Files and Instance Main Methods

This one's a bit of a mouthful: "compact source files and instance main methods". Instance main methods allow the entry point to a program to be just void main, meaning neither public nor static nor needing arguments. And compact source files contain a main method but no class declaration and they auto-import java.base, so collections, dates and times, file I/O, system interaction, etc. all are readily available. And then there's the new class IO, which makes it simpler to write to and read from the terminal - and it is now backed by System.out and in, by the way.

// FROM THIS
import java.util.List;

class Main {

	public static void main(String[] args) {
		System.out.println(List.of("Hello", "World"));
	}

}

// TO THIS
void main() {
	IO.println(List.of("Hello", "World"));
}

All this is is final in JDK 25 and that's great for beginners but also for the growing crowd of Java ponies like me who use it to write scripts. In Java. Java scripts, so to speak.

Primitive Patterns

This last language feature is still in preview in JDK 25 and unchanged over 24 - still looking for more feedback. It's about adding primitive types to patterns, instanceof, and switch, which primarily files off a few weird edge cases the language would otherwise have but is also handy when doing primitive conversion or pattern matching over types that contain primitives or their wrappers.

Object obj = // ...

switch (obj) {
	case Point p -> // ...
	// ✅ primitive pattern
	case int i -> // ...
	// more cases
}

// ✅ primitive pattern
if (obj instanceof float f) {
	// matches, e.g., `obj = 1L`
}

Boolean b = // ...
switch (b) {
	// ✅ primitive pattern
	case true -> // ...
	case false -> // ...
	case null -> // ...
}

For example, with a switch(bool) case true case false case null you can now kick that non-binary Boolean's butt!

Key Derivation Function

With language features covered, let's turn towards APIs. clearing throat

Key Derivation Functions (KDFs) make use of cryptographic inputs, such as initial key material, a salt value, and a pseudorandom function, to create new cryptographically strong key material. A KDF is often used to create cryptographic data from which multiple keys can be obtained. A KDF allows keys to be created in a manner that is both secure and reproducible by two parties sharing knowledge of the inputs.

After the key encapsulation mechanism in JDK 21, the KDF API, which is final in JDK 25, is the second in a series of steps Java takes towards supporting Hybrid Public Key Encryption, which enables the smooth transition to quantum-safe encryption algorithms. This is of critical importance for the platform - already now, so that data intercepted and stored today can not be readily decrypted in a world with quantum computing.

// create a KDF object for the specified algorithm
var hkdf = KDF.getInstance("HKDF-SHA256");

SecretKey initialKeyMaterial = // ...
byte[] salt = // ...
byte[] info = // ...
// create an ExtractExpand parameter specification
var params = HKDFParameterSpec
		.ofExtract()
		.addIKM(initialKeyMaterial)
		.addSalt(salt)
		.thenExpand(info, 32);

// derive a 32-byte AES key
SecretKey key = hkdf.deriveKey("AES", params);

Scoped Values

Scoped values have been in preview for four releases now and are finally final in JDK 25. This API is about sharing immutable references to data with callees within a thread and within child threads in a way that is easier to use, more comprehensible, robust, and performant than thread-locals. This comes at the expense of only passing data one way and within a predetermined scope, which is by far the most common use case.

static final ScopedValue<Integer> ANSWER =
	ScopedValue.newInstance();

void main() {
	ScopedValue
		.where(ANSWER, 42)
		// prints "42"
		.run(() -> IO.println(ANSWER.get()));

	// ~> NoSuchElementException
	ANSWER.get();
}

If you stumbled over the term "child threads", let's talk about structured concurrency next.

Structured Concurrency

The structured concurrency API rethinks how to organize concurrency. It hinges on the idea that if a task splits into concurrent subtasks, the task should await their completion, and process their errors or results in the same scope.

try (var scope = StructuredTaskScope.open()) {
	// fork subtasks
	var user = scope.fork(this::fetchUser);
	var order = scope.fork(this::fetchOrder);

	// wait for completion
	scope.join();

	// process results
	IO.println(user.get() + order.get());
} catch (Exception ex) {
	// process errors
}

This structure comes with a number of benefits:

clarity of code that always follows the same procedure:
- set up the subtasks
- wait for them to either complete or be cancelled
- decide whether to succeed or fail
error handling with short-circuiting, where a failing subtask can cancel other, ongoing subtasks
cancellation propagation, where if a task gets canceled, so do all of its subtasks, potentially down a large tree of tasks
parent-child relationships between the thread running the task and those running the subtasks
observability, where a thread dump clearly displays this thread/task hierarchy

The API is in its fifth preview in JDK 25 and has seen a noticeable revamp over its earlier previews. If you have the chance, give it a try and report your experience to the loom-dev mailing list.

Stable Values

The stable values API offers lazy, exactly-once initialization that, at the same time, enables aggressive just-in-time performance optimizations. This comes from close cooperation with the runtime where the reference to the instance, once it gets created, is truly final and can't even be changed through reflection - something that is also true for record fields but not for final fields in regular classes.

The API follows a functional approach where invocations of, for example, StableValue::supplier return a Supplier of the desired instance. Similar methods exist that return lazily populated collections.

// STABLE VALUE :: SUPPLIER
private final Supplier<Answer> answer =
	StableValue.supplier(() -> new Answer(42));

Answer getAnswer() {
	// constant computed on
	// first `get` invocation
	return answer.get();
}

// STABLE VALUE :: LIST
private final List<Answer> answers =
	StableValue.list(42, Answer::new);

// list with indices 0-41
List<Answer> getAnswers() {
	// each constant is first computed on
	// `answer.get(index)` (or similar)
	return answer;
}

Stable values are new in JDK 25 and in their first preview.

PEM Encodings of Cryptographic Objects

I'm sure you've seen these textual representations of cryptographic keys that start with five dashes, then in all-caps "BEGIN PUBLIC KEY", for example, followed by another five dashes. Then comes a Base64-encoded representation of the key before the whole thing ends similarly to how it started.

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD
QgAEi/kRGOL7wCPTN4KJ2ppeSt5UYB6u
cPjjuKDtFTXbguOIFDdZ65O/H8TUqS/s
VzRF+dg7H3/tkQ/K36dtuADbwQ==
-----END PUBLIC KEY-----

The most likely place where you handled them is when you uploaded SSH or PGP keys to GitHub or artifact repositories. Those text blocks were originally standardized to exchange cryptographic objects via email and so the standard is called Privacy Enhanced Mail, or PEM for short.

Starting as a preview in JDK 25, Java gets an API that can convert between PEMs and cryptographic objects that have standard representations in the binary formats PKCS#8 1.2 and 2.0 as well as X.509. This includes private and public keys, certificates, and certificate revocation lists.

public sealed interface DEREncodable permits
	// these types already exist;
	// they now implement `DEREncodable`
	AsymmetricKey, KeyPair,
	PKCS8EncodedKeySpec, X509EncodedKeySpec,
	EncryptedPrivateKeyInfo,
	X509Certificate, X509CRL,
	PEMRecord {
		// no methods
}

public final class PEMEncoder {

	public String encodeToString(DEREncodable so);

	// [... more API ...]

}

public final class PEMDecoder {

	public DEREncodable decode(String str);

	// [... more API ...]

}

JEP 470: PEM Encodings of Cryptographic Objects (Preview)

Vector API

...

Generational Shenandoah

Ok, let's talk about runtime improvements and we'll start with garbage collection. Shenandoah gained an experimental generational mode in JDK 24 and after many stability and performance improvements, it's no longer experimental in 25 but considered production-ready. It is not the default mode of Shenandoah, though, and still needs to be enabled with -XX:ShenandoahGCMode=generational. THis is in addition to -XX:+UseShenandoahGC, of course. What you don't need anymore is -XX:+UnlockExperimentalVMOptions.

JEP 521: Generational Shenandoah

AOT Method Profiling

Project Leyden pushes out its second launch time improvement, this one focused on warmup time - the time between the first useful unit of work and peak performance. One thing the JVM does during that time is profiling methods to find out which are worth optimizing and how. If that happens during the training run and the profiles are stored in the AOT cache, they can be loaded from there instead of being collected in production and the JIT compiler can generate native code immediately upon application startup.

In JDK 25, this happens automatically during the AOT workflow, doesn't add any new constraints nor require code changes, and just like class-loading and linking will also be overruled at runtime if it turns out that the cached information doesn't line up with reality.

JEP 515: Ahead-of-Time Method Profiling

AOT Command-Line Ergonomics

So that new AOT optimization doesn't change the workflow, but this feature does. The AOT command triad is:

observe a training run to create a cache configuration
create a cache from it
run the application with the cache

# training (⇝ profile)
$ java -XX:AOTMode=record
	-XX:AOTConfiguration=app.aotconf
	-cp app.jar com.example.App ...
# assembly (profile ⇝ AOTCache)
$ java -XX:AOTMode=create
	-XX:AOTConfiguration=app.aotconf
	-XX:AOTCache=app.aot
	-cp app.jar
# production (AOTCache ⇝ 🚀)
$ java -XX:AOTCache=app.aot
	-cp app.jar com.example.App ...

Starting in JDK 25, this workflow can be optionally shortened by combining the first two steps into one, so the result of the training run isn't a configuration, but the actual cache, ready to be used in production.

# training (⇝ AOTCache)
$ java -XX:AOTCacheOutput=app.aot
	-cp app.jar com.example.App ...
# production (AOTCache ⇝ 🚀)
$ java -XX:AOTCache=app.aot
	-cp app.jar com.example.App ...

This will cover all simple and many advanced cases but more complex configurations may still need to manually invoke all three steps.

JEP 514: Ahead-of-Time Command-Line Ergonomics

Compact Object Headers

Every object on the heap has a so-called header that the JVM uses to track certain information, for example for typing, locking, and garbage collection. From the point of view of the application, the additional memory consumption is overhead and ideally would be zero, but that's not going to happen. But compact object headers, which were introduced as an experimental feature in JDK 24, provide an alternative object header layout that reduces the overhead by a third to half, which reduces overall memory consumption by 10-20% in typical cases.

After thorough validation through extensive testing and production runs this feature is now considered production-ready. On JDK 25, you can enable it with the flag -XX:+UseCompactObjectHeaders. While this has a really good chance to reduce memory consumption and even CPU times (through denser memory layout and reduced pressure on garbage collection), this is not guaranteed to be the case, so observe your application carefully and verify that it actually helps.

JFR Method Timing & Tracing

To make it easier to time and trace invocations, be it to identify performance bottle necks in production, to optimize code, or to debug production issues, two new JDK Flight Recorder events are introduced: jdk.MethodTiming and jdk.MethodTrace.

# time the execution of all static initializers:
$ java '-XX:StartFlightRecording:method-timing=::<clinit>,filename=clinit.jfr' ...
$ jfr view method-timing clinit.jfr

                                 Method Timing

Timed Method                                           Invocations Average Time
------------------------------------------------------ ----------- ------------
sun.font.HBShaper.<clinit>()                                     1 32.500000 ms
java.awt.GraphicsEnvironment$LocalGE.<clinit>()                  1 32.400000 ms
java2d.DemoFonts.<clinit>()                                      1 21.200000 ms
java.nio.file.TempFileHelper.<clinit>()                          1 17.100000 ms
sun.security.util.SecurityProviderConstants.<clinit>()           1  9.860000 ms
java.awt.Component.<clinit>()                                    1  9.120000 ms
sun.font.SunFontManager.<clinit>()                               1  8.350000 ms
sun.java2d.SurfaceData.<clinit>()                                1  8.300000 ms
java.security.Security.<clinit>()                                1  8.020000 ms
sun.security.util.KnownOIDs.<clinit>()                           1  7.550000 ms
...

# profile `HashMap::resize` to determine what causes resizes:
$ java -XX:StartFlightRecording:jdk.MethodTrace#filter=java.util.HashMap::resize,filename=recording.jfr ...
$ jfr print --events jdk.MethodTrace --stack-depth 20 recording.jfr
jdk.MethodTrace {
    startTime = 00:39:26.379 (2025-03-05)
    duration = 0.00113 ms
    method = java.util.HashMap.resize()
    eventThread = "main" (javaThreadId = 3)
    stackTrace = [
      java.util.HashMap.putVal(int, Object, Object, boolean, boolean) line: 636
      java.util.HashMap.put(Object, Object) line: 619
      sun.awt.AppContext.put(Object, Object) line: 598
      sun.awt.AppContext.<init>(ThreadGroup) line: 240
      sun.awt.SunToolkit.createNewAppContext(ThreadGroup) line: 282
      sun.awt.AppContext.initMainAppContext() line: 260
      sun.awt.AppContext.getAppContext() line: 295
      sun.awt.SunToolkit.getSystemEventQueueImplPP() line: 1024
      sun.awt.SunToolkit.getSystemEventQueueImpl() line: 1019
      java.awt.Toolkit.getEventQueue() line: 1375
      java.awt.EventQueue.invokeLater(Runnable) line: 1257
      javax.swing.SwingUtilities.invokeLater(Runnable) line: 1415
      java2d.J2Ddemo.main(String[]) line: 674
    ]
}

They allow execution times and stack traces to be recorded for specific methods, which are selected on the command line, in configuration files, with jcmd, or JMX and, unlike sample-based profilers, they record complete and exact statistics. But this can impose a larger CPU overhead than the 1% JFR generally aims for and should be used for a few methods at a time - for larger numbers, sampling-based approaches remain recommended. Which brings us to our second JFR improvement.

JEP 520: JFR Method Timing & Tracing

JFR Cooperative Sampling

When sampling data, it's essential to prevent selection biases. If, for example, I'd ask all of you to post your favorite programming mascot's name in the comments, I couldn't really expect a representative outcome, now, could I? So when JFR samples stack traces to create execution-time profiles, it's important to do that in regular intervals, but the issue is that the stack can only be reliably parsed in what's called a safepoint. This essentially jiggles the sample points into these safepoints, which results in what's called safepoint bias, where a frequently executed span of code might not even show up in the profile because it doesn't contain a safepoint.

JFR currently works around this by parsing the stack in fixed intervals with an unreliable heuristic and hoping that this works out often enough to lead to good results. Starting in JDK 25, JFR combines the best of both worlds by emitting sample requests in regular intervals that are then reliably reconstructed to full stack traces at the next safepoint.

JEP 518: JFR Cooperative Sampling

JFR CPU-Time Profiling

Editing Nicolai here, bringing you a feature that was targeted to JDK 25 just an hour ago at time of recording this: JFR CPU-time profiling. Based on a kernel signal that is emitted at fixed intervals of CPU time, JFR can now create CPU-time profiles for Java programs. They differ from the more common real-time profiles in that they do not include the time spent waiting for memory, the file system, network I/O, etc. Neither of these profiles is strictly better than the other - real-time profiles are most helpful to reduce latency whereas CPU-time profiles are crucial to identifying CPU-intense methods, which can limit throughput.

For now, this feature only works on the best of operating systems and is experimental. Check JEP 509 for details, give it a try, and let the folks on the hotspot-jfr-dev mailing list know about your experience.

JEP 509: JFR CPU-Time Profiling (Experimental)

32-bit x86 Removal

And finally, bad news for everyone who's using 32-bit x86 hardware, although that's not gonna be a lot of you, if any. That port of the JDK was removed entirely in JDK 25, which means that new features like virtual threads, FFM, or the vector API no longer need to implement 32bit fallbacks, which was a major opportunity cost. It also simplifies the JDK's build and test infrastructure.

JEP 503: Remove the 32-bit x86 Port

For more details, check the JEP that I linked in the description, which I did for all of these features, by the way, or wait for an upcoming episode of the Inside Java Podcast, where I discuss this and other deprecations and removals with the one and only Dr. Deprecator.

Until then, be sure to check out the JDK 25 EA builds, and I'll see you again in two weeks. So long...

Watch the video.

Structured Concurrency Revamp in Java 25 - Inside Java Newscast #91

Nicolai Parlog — Thu, 08 May 2025 00:00:00 GMT

JDK Enhancement Proposal 505 revamps the structured concurrency API in JDK 25 by introducing a configuration and joiners.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about JDK Enhancement Proposal 505, which revamps the structured concurrency API in JDK 25. That's the API that most Java applications will use to organize most of their concurrency and given that it leverages the utility of virtual threads, I want to hazard a guess that we'll use it more often than we use thread pools today. Ready? Then let's dive right in.

Structured Concurrency

Before we get into the weeds of JEP 505, let's make sure we're all on the same page on the concept of structured concurrency. If you're a regular viewer of this channel, this won't be news to you - feel free to skip this chapter. Everybody else, I will only give the briefest of introductions here. If you got an extra six minutes, check Inside Java Newscast #17, and if you're in the market for a deeper dive, there's this excellent half-hour talk by Alan Bateman, the owner of JEP 505.

Ok, let's go! Structured concurrency derives from a simple principle: If a task splits into concurrent subtasks, then they all return to the same place, namely the task's code block.

So instead of committing subtasks to a thread pool over there and then passing around futures to which you add result processing and error-handling all over the place, waiting for their results who-knows-where, these subtasks are treated as a single unit of work. A single method has the responsibility to handle the entire concurrency lifecycle of a set of related subtasks, while the task that spawned them waits for their completion. While before, there were independent threads passing in the night, this restriction captures the natural relationship between tasks and subtasks and instills structure: A parent thread that waits for its child threads to complete their work before it continues.

And it's this structure that brings a number of downstream benefits:

clarity of code that always follows the same procedure:
- set up the subtasks
- wait for them to either complete or be cancelled
- decide whether to succeed or fail
error handling with short-circuiting, where a failing subtask can cancel other, ongoing subtasks
cancellation propagation, where if a task gets canceled, so do all of its subtasks
observability, where a thread dump clearly displays the task hierarchy

Now let's see how to actually do that in Java.

Structured Concurrency in JDK 25

JDK 25 previews the structured concurrency API for the fifth time, with considerable changes over its previous version. The core type remains the same, though - it's StructuredTaskScope and works as follows:

you get an instance by calling the static open method - in JDK 24 you used to call a constructor
you fork subtasks by passing a Callable or Runnable to the fork method, which runs them on a new virtual thread
then you call join, which will block until... for now we'll say until all subtasks complete - unlike in JDK 24, join will throw all subtask-related exceptions, so no more throwIfFailed-method.
finally, there's close but since you'll use structured task scopes in try-with-resources blocks, you won't have to explicitly call that

try (var scope = StructuredTaskScope.open()) {
	var user = scope.fork(this::fetchUser);
	var order = scope.fork(this::fetchOrder);

	scope.join();

	// process results
	IO.println(user.get() + order.get());
} catch (Exception ex) {
	// error handling
}

The big difference between previous previews and this one is how to configure or even customize the behavior of a structured task scope:

In JDK 24, the type StructuredTaskScope is a non-final class. It has multiple subclasses that cover most use cases but if yours isn't among them, you can create your own.
In JDK 25, it's a sealed interface with I-don't-know-how-many implementations, but they're internal and we cannot add our own. Instead, we configure task scopes with a config and joiners, more on both of them in a minute. Where they are not powerful enough, you'd need to create your own API that wraps a task scope.

That last aspect speaks to a point the JEP makes:

It is not a goal to create the definitive structured concurrency API for all Java programs. Other structured concurrency constructs can be defined by third-party libraries or in future JDK releases.

And, while you can reimplement the aforementioned short-circuiting error handling and cancellation propagation yourself, establishing parent-child thread relationships for better observability is currently out of reach for non-JDK APIs. So our structured concurrency APIs will probably wrap a StructuredTaskScope and forward calls to its fork method. If you end up going down that road, please let the folks on the Loom mailing list know - they're interested to learn about your use case. But before you make that call, you should know what the configuration and joiners can do for you, so let's take a look at that next.

Configuration

Three properties of a structured task scope can be configured:

a name for the scope - as we'll see later, this serves monitoring purposes only
the thread factory the scope uses to create threads for each forked subtask
a timeout, which starts when open is called and, if it times out, cancels all remaining subtasks and throws an exception from join

These properties are defined by an instance of StructuredTaskScope.Configuration and the default configuration has neither name nor timeout and uses a thread factory that creates virtual threads without name. To change the defaults, use the overload of open that accepts a function as an argument, which will be called with the default config to return a new config as output.

try (var scope = StructuredTaskScope.open(
	/* ... */,
	cf -> cf
		.withName("weather-forecast")
		.withTimeout(Duration.ofSeconds(2))
)) {
	// ...
}

Joiners

Earlier, I waffled a bit when I said that join will block until all subtasks complete because, generally speaking, that's not correct. It's the task of a so-called Joiner...

to react to subtask completion, be they successful or not
to cancel the scope early if desired
to create the exception that join will throw in a failure case
to produce a result that join will return (where that is applicable)

And such a joiner can be passed to an overload of open.

try (var scope = StructuredTaskScope.open(
	/* JOINER GOES HERE */,
)) {
	// ...
}

If the parameterless variant of open is called, a default joiner is used, which behaves as follows:

it does not react to successful completion of subtasks
it will cancel the scope if a subtask fails
and in that case, it will throw the failed subtask's exception
in the case of all subtasks completing successfully, no result is computed for join - the user is expected to get results from the subtasks themselves

try (var scope = StructuredTaskScope.open() {
	var user = scope.fork(this::fetchUser);
	var order = scope.fork(this::fetchOrder);

	scope.join();

	// extract results from subtasks
	IO.println(user.get() + order.get());
} catch (FailedException ex) {
	// a subtask failed
}

This means that the default joiner works well for subtasks with different result types that must all complete successfully. And now we can jiggle these requirements and see what combinations we get. So, for example:

All subtasks return the same type and all must succeed. That means a failed subtask cancels the scope but a successful scope can return a stream of these results directly from join.

try (var scope = StructuredTaskScope.open(
	Joiner.allSuccessfulOrThrow()
)) {
	scope.fork(this::forecastA);
	scope.fork(this::forecastB);
	scope.fork(this::forecastC);

	var forecasts = scope
		.join()
		.map(Subtask::get)
		.toList();

	// use `forecasts`
} catch (FailedException ex) {
	// a subtask failed
}

All subtasks return the same type but only one needs to succeed. That means as soon as the first subtask completes successfully, the scope is canceled and the subtask's result is returned from join. Only if all subtasks fail, will the scope itself fail as well.

try (var scope = StructuredTaskScope.open(
	Joiner.anySuccessfulResultOrThrow()
)) {
	scope.fork(this::forecastA);
	scope.fork(this::forecastB);
	scope.fork(this::forecastC);

	var forecast = scope.join();

	// use `forecast`
} catch (FailedException ex) {
	// all subtasks failed
}

Subtasks can return result types that are different and we want all to complete, successfully or not, before moving on. This joiner is very lazy and essentially does nothing. It's up to the user to interrogate subtasks for their state and to get results where they are available.

try (var scope = StructuredTaskScope.open(
	Joiner.awaitAll()
)) {
	var fcA = scope.fork(this::forecastA);
	var fcB = scope.fork(this::forecastB);
	var fcC = scope.fork(this::forecastC);

	scope.join();

	// interrogate subtasks, e.g.
	var resultA = switch (fcA.state()) {
		case FAILED ->
			fcA.exception().getMessage();
		case SUCCESS ->
			fcA.get().toString();
		case UNAVAILABLE ->
			throw new IllegalStateException();
	};
}
// no `FailedException` will be thrown

And, wouldn't you know it, there's a factory method for each of these cases on Joiner (plus one that I spared you here), so you don't have to implement these yourself. If you want to, though, it's not too complicated - Joiner has only the three methods. But be aware that implementations must be thread-safe as subtask completion can happen in multiple threads at the same time. And also, joiner instances can be stateful, so back at the use site, they should absolutely not be shared between scopes.

Odds & Ends

JEP 505 goes deeper into a number of details that I want to at least mention here:

join can throw a variety of exceptions, depending on whether the scope is misused, has failed, timed out, or was cancelled.
About misuse: The API insists on the restrictions of structured concurrency and will throw if it detects misuse, for example when code exits the scope without having called join or when join is invoked by the wrong thread.
Cancellation is propagated via thread interrupts, meaning primarily as InterruptedExceptions during blocking calls, both up and down the tree of nested structured task scopes. Cancelled scopes will always cancel all remaining subtasks and a cancelled subtask may cancel the scope that owns it, depending on what the joiner decides.
Both structured concurrency and scoped values lean on nested scopes in a way that aligns perfectly and so subtasks automatically inherit a task's scoped values. If that sentence didn't make too much sense, check Inside Java Newscast #86. Oh, and JEP 506 proposes to finalize scoped values in JDK 25.
jcmd can print a thread dump, which comes as a tree of nested scopes and includes the scope and thread names. This is a huge improvement in understanding a concurrent application's state.
Last but not least, JEP 505 is currently proposed to target JDK 25 and I'm very optimistic that it will be targeted and integrated soon. If you cannot wait that long, try the Project Loom early access build, which has had this API for quite a while now - link in the description.

I'll see you again in two weeks. So long...

Watch the video.

JavaOne'25 Highlights - Inside Java Newscast #89

Nicolai Parlog — Thu, 10 Apr 2025 00:00:00 GMT

JavaOne 2025 had lots of talks from OpenJDK insiders as well as from community experts - here are some of the highlights

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today I'm gonna share with you:

an explanation for why not to use unit tests for AOT training runs on JDK 24
a garbage collection primer and comparison
two tips on how to analyze your Maven build
the announcement that final will eventually mean really final and how to simulate that today
a detailed look at how to build an advanced retrieval augmenter for querying AI models
and last but not least, the roadmap for value types and null restriction, but no timeline, so don't get too excited

All of this and so much more was discussed at JavaOne 2025 a few weeks ago, where we had lots of talks from both OpenJDK insiders as well as from community experts. A few recordings are already online, the others will be published over the coming weeks - subscribe or track this playlist if you don't want to miss them.

Ready? Then let's dive right in.

Unit Tests for AOT Training Runs

During one of our live streams, I talked to Dan Heidinga, who works on Project Leyden, about ahead-of-time class loading and linking in JDK 24 and specifically about training runs when he told me this:

The big thing you want to avoid with a training run is loading classes that you don't need in your production run. So if your benchmark loads a whole bunch of classes that will never be used in production that may not be the best training run.

That also excludes unit tests by definition right because like the entire unit testing framework and assertion libraries and all of that is in there.

It does. There are probably ways you can configure things to make that more useful because what we've done so far and what we've shipped in JDK 24 optimizes the three built-in class loaders. So, the system loader, the application loader, and the extension loader.

So unit tests are not only questionable training runs because they execute the application code very differently from a production run, with a default configuration they also pollute the cache with lots of unnecessary classes. I think the configuration Dan has in mind to fix this would load your application code into the application class loader but the testing framework, assertion library, etc. into a custom class loader that the AOT cache would ignore.

GC Primer and Comparison

There were a bunch of really good talks about garbage collection. The segment I picked here is pretty early in Stefan Johansson's talk. He gives a high-level overview over GC performance aspects and the strengths of each OpenJDK GC:

In many cases we talk about three different aspects here:

The first being throughput - you care mostly about throughput. And what we mean by that is the number of transactions that you can complete in a set amount of time.

Then we also have latency, which is more about a single transaction. Is that affected by, say for example, a GC pause, the latency can be bad and the transaction can take a long time.

And then we have footprint - the overhead caused by the GC algorithm.

It's very hard to optimize for all of these at once, so usually we have to do a lot of trade-offs. And if we try to illustrate a trade-off, it can look something like this: We have a set of application threads. At some point, we realize we need to do garbage collection work. We do this in a GC pause using multiple threads, trying to make sure that the GC pause is as short as possible before letting the application threads run again.

This is pretty good from a throughput perspective because when the application threads run, no GC work is going on, so you don't have to compete for CPU resources. On the other hand, from a latency point of view, it's not optimal because we have the GC pauses and they take a significant amount of time.

So if we care more about latency, we can have something that looks a bit more like this: So, again, we have the application threads, but when we realize we need to do garbage collection work, we do a very short GC pause and instead do the heavy GC work concurrently with the Java application threads running. So from a throughput perspective, this might be a little bit worse because the GC threads and the application threads compete for the same resources. On the other hand, latency-wise it's much better because the GC pauses are much much shorter.

In Open JDK today, we have five different garbage collectors:

We have Serial, which has a main focus on low memory overhead.

We have Parallel, which is a throughput-collector aiming to provide as good throughput as possible.

We have G1, or the Garbage First collector, which has a balanced performance profile.

And then we have ZGC and Shenandoah, which both aim at providing good low latency alternatives for Java

Stefan then dives deeper into performance improvements of these GCs across Java versions and recounts the positive outcomes Netflix, Mercado Libre, LinkedIn, and OCI had when upgrading their runtimes. Another great talk in this space that I can recommend is from Erik Osterlund on ZGC.

Analyze Your Maven Build

Have you ever been confused by your Maven build? Maybe why it's taking so long? If not, I can only assume, you've never used Maven - and I'm not hating on it, it's just that real-life projects tend to get messy and their builds are no exception. Watch Richard Fichtner use an extension and a plugin to gain some insights.

We need something special and this time it's not a Maven plugin, we need an extension. So what's the difference between a plugin and extension? An extension is better, bigger, and can see the class loader for the plugins because we need that to profile the plugins.

Let me show you how this looks: looks something like this. We will create a file called extensions.xml - looks like this. So very similar to a plugin and you put it in the .maven folder of your project and it's in Git, so it's in version control, so you don't have to touch the build server, the CI, nothing. So this is now there. But be cautious as they have a lot of rights and access - don't trust everything. I know this is a good plugin because this is from Karl-Heinz Marbaise.

And let's do mvn verify first, of course. Okay, we get some things. I get some numbers for my pizza backend and it tells me "okay, there's a lot of things going on" and how much each phase took.

And to understand that a little bit better, we can use a build plan plugin to see what is happening. And this was very good for me to see this when I saw it the first time to better understand what is happening and this plugin has more goals with other outputs. And here you can see that in the validate phase we have two plugins registered that will run when I do validate. When I do compile, basically everything before that runs and you can see actually what's going on. In this example, of course, this is easy, this is not the real world. Run this on your project that you're working on day-to-day and you will see crazy things if the project is older than maybe 10 days.

If you're wondering about the short burst of music during his build or why to prever mvn verify oder mvn clean install, don't miss his talk.

Truly Final

I also recorded two long conversations that will end up as episodes of the Inside Java Podcast, which you can find pretty much everywhere but just to make sure, there's a link in the description. One was with Mark Reinhold who dropped big news and then preempted their announcement here by publishing a JEP draft a few days after JavaOne. Not cool, Mark!

There's a new API called stable values, which does a few things, but mainly the idea is to have finality for something that is initialized late. But that then is really, really final just like the record components are really, really final and I'm going to go out and guess that probably Valhalla's value types' fields are also really, really final.

They are so final you wouldn't believe how final those fields are.

Is there any way to backport that? Like, could you give me a flag where I say I want final to mean final and, you know, screw the code in my codebase or my dependencies that doesn't respect that. Because, you know, in that case I guess setAccessible would throw an exception, so I would probably find out at runtime if I had a problem.

There is a JVM flag... I forget what its name is... starts with the letters XX.

Okay, we'll put it on screen, maybe here, in post-production. But, so, are there ideas to make TrustFinal an option or maybe even the default?

Oh, no, we plan to make it the default over time and there is a JEP already to prepare to make final fields mean final.

Oh really there's a JEP? A JEP draft, I hope at least, otherwise I would feel kind of ashamed that I don't know that.

Okay, so just delete this in post-production - I'll look it up.

Building Advanced RAG

As you can imagine, a big chunk of talks related to AI in some way, shape, or form. From OpenJDK's code reflection and HAT to various frameworks, from the announcement of Oracle Code Assist to coding guidelines and security concerns - just so much AI. I picked a short section from Lize Raes's and Mohamed Ait Abderrahman's presentation of a research agent where they explain how they build its advanced retrieval augmentation pipeline, which is essential to get the best possible replies from the AI model you'll eventually query.

To mitigate all these little problems, we came up with this retrieval augmenter in LangChain4j, so instead of just a content retriever we now have the augmenter. It's all interfaces, so if you want to build your own version of it, you can. I've put underneath our default implementations that you can easily use.

So let's start in the middle there with content retrievers. Instead of having one content retriever that searches in your documents, you can have multiple ones and they can also do more things. So we have an embedding store that's going to search in your documents but you also have graph RAG, SQL, and a web search engine coming out of the box. You can write your own one for any API calls, for example if you wanted a weather service.

Now, how do we know which content retrievers to pick? There's a query router in front of that, typically also powered by an LLM, that's going to say "Oh given this query and given all these content retrievers I have, I'm going to send it there or there or to multiple at the same time." And it's going to also rewrite your query because a web search query of course is very different from an SQL query and LLMs can write proper queries.

Then, in front we have this query transformer that I talked about before. The compressing query transformer will take your history into account to make a sensible question and not just "yes, please". Expanding query transformer will make it into even more questions so it's sure to find the answer.

At the other side, once the content pieces are retrieved, we can just put them together in the default content aggregator - it's just going to put one after the other. But very often there are pieces in there that are irrelevant to the question after all and typically they will confuse your model and your model will answer something that had nothing to do with the original question, you will wonder why. Well it's because RAG found pieces that were, like for example, if it has started talking about the book it found there, it could have happened.

So we also added a re-ranking content aggregator. It calls a small scoring model that has one function "How relevant is this piece of content to the question" and it will kick out everything that's not relevant enough. Content injector will just add the original question and all the pieces of information that are important, too, and that's what is sent off to the model.

Valhalla Roadmap

Even though he won't say it, Brian is giving off strong "Valhalla soon" vibes. In his talk about Java's language evolution, he even went so far to show a roadmap, meaning a list of JDK Enhancement Proposals that cover Valhalla's first feature arc and the order in which he expects them to land.

So, there's a bunch of JEPs on the road map, some of them have numbers, some of them don't yet have numbers. JEP 401 is the first piece - It's basically value classes and that's it. And that is well underway:

the spec has been stable for over a year

we're just polishing the implementation

there's a second early access coming out fairly soon

And then, you know, looking a little farther down the road there's null restricted types as a concept on their own, there's null restricted types in the context of value types, which adds in some interactions and optimizations, and then there's sort of a cleanup-JEP to minimize the gap between the legacy primitives and the null-restricted variant of their box types. And I'm sure these are not going to be the only four.

Cool, cool, can't wait. But now I'm heading off to a holiday, which means that in two weeks you'll have to make do with Billy. Say "hi" to him from me, maybe make a joke about the monstrosity he calls a haircut, and I'll see you again in May. So long...

Watch the video.

New Null Checks in Inner Class Constructors

Nicolai Parlog — Fri, 04 Apr 2025 00:00:00 GMT

The Java compiler will now inject null checks for the outer instance into the constructor of inner classes

Null Enclosing Instance

The Java Language Specification prescribes that various use sites of inner class constructors should include null checks of the immediately enclosing instance and from then on assumes that the reference is non-null. However it does not mandate such checks of the incoming instance at the declaration site of these constructors and so core reflection, method handles, and direct bytecode invocation can pass null as enclosing instance, which can lead to NullPointerExceptions down the road.

Since a null enclosing instance is outside of the JLS and the future evolution of inner classes may lead to unexpected NPEs, Java 25 will start ensuring that references to the immediately enclosing instance are always non-null.

Emitted Null Checks

Starting with JDK 25, when javac is targeting release 25 or higher, it will emit null checks for the enclosing instances in inner class constructors.

This behavioral change will lead to new NPEs in code that uses core reflection, method handles, or direct bytecode invocation to pass null as enclosing instance. Such code is rare and usually found in libraries or frameworks (as opposed to in applications). It should be changed to no longer pass a null reference.

In case these additional checks lead to issues, their emission can be prevented with a flag: -XDnullCheckOuterThis=(true|false). This should be seen as a temporary workaround and no guarantees are made for how long this flag will be available.

For more details, check JDK-8351274.

Scoped Values in Java 24 - Inside Java Newscast #86

Nicolai Parlog — Thu, 27 Feb 2025 00:00:00 GMT

Scoped values enable a method to share immutable data both with its callees within a thread and with child threads in a convenient, safe, scalable way, particular in comparison to thread-local variables.

Ready? Then let's dive right in.

Passing Data

All non-trivial methods have data as input. Most commonly these are method arguments or instance fields, but there are exceptions where a method draws from static fields from its own class or even from another class.

(Gasp! Really, no one else gasped?)

Yes, yes, such package-local or even global state is a huge red flag, but you know how it is, you can't make an omelette without... red flags? I feel like the metaphors got away from me here...

Anyways, sometimes a method needs data that, for some reason or another, can't be passed as an argument or consigned to an instance field. You may be writing a framework where control passes from your code to user code and back to you but you don't want to burden users with passing along arguments that are useless to them or have security implications. Or maybe you're using something that isn't thread-safe but highly mutable like a graphics context. Or maybe you need to keep track of thread-specific context information, for example a request ID for logging or a transaction ID to flatten nested transactions. None of these use cases are terribly common in our code, which is why we don't often do this, but it's also not unheard of, which is why Java has a solution for this. Now two, actually. Let's discuss the new one first and then I'll contrast it with the old solution and explain why a new one was needed.

Scoped Values

JDK 24 previews scoped values for the fourth time. Let me quote from JEP 487:

A scoped value is a container object that allows a data value to be safely and efficiently shared by a method with its direct and indirect callees within the same thread, and with child threads, without resorting to method parameters. It is a variable of type ScopedValue. It is typically declared as a static final field, and its accessibility is set to private so that it cannot be directly accessed by code in other classes.

On that last one, I want to add that private should be your default but package or even global visibility isn't unheard of.

(Gasp! Oh, come on! That was gasp-worthy, there's something wrong with you people.)

Ok, so what do you do with a scoped value except declaring it? In order to use it, you have to bind it to some data and then pass a lambda that will be immediately executed. The lambda and all code called from it will be able to access the data by calling get() but once it ran its course, the data will be cleaned up and no other code can access it.

static final ScopedValue<Integer> ANSWER =
	ScopedValue.newInstance();

void main() throws Exception {
	ScopedValue
		.where(ANSWER, 42)
		// prints "42"
		.run(() -> IO.println(ANSWER.get()));

	// ~> NoSuchElementException
	ANSWER.get();
}

That means the data (the value) is only accessible within the scope of the lambda - hence the name ScopedValue - which makes the code easy to reason about.

static final ScopedValue<Integer> ANSWER =
	ScopedValue.newInstance();

void main() throws Exception {
	ScopedValue //      ⬐ VALUE
		.where(ANSWER, 42)
		//  |<---------- SCOPE ----------->|
		.run(() -> IO.println(ANSWER.get()));

	// OUT OF SCOPE
	ANSWER.get();
}

Immutability and Nesting

Leaning further into ease of use, scoped values also prohibit setting new data, so the called code cannot set something that the calling code can later read - data transmission is one-way from caller to callee. That said, code can rebind the scoped value for its callees. This may sound confusing, but it's actually pretty straightforward, just think of nested scopes:

method A binds 42 and then calls method B
B can then get 42 from the scoped value, rebind it to, say, 43, and then call method C
when C calls get it reads 43 - no way to see 42 and also no way to write anything to the scoped value that the outer scope, that B can observe
when control flow eventually returns from C to B, it in turn only sees 42

static final ScopedValue<Integer> ANSWER = ScopedValue.newInstance();

void a() {
	ScopedValue
		.where(ANSWER, 42)
		.run(this::b);
}

void b() {
	// prints "42"
	IO.println(ANSWER.get());
	ScopedValue
		.where(ANSWER, ANSWER.get() + 1)
		.run(this::c);
	// prints "42"
	IO.println(ANSWER.get());
}

void c() {
	// prints "43"
	IO.println(ANSWER.get());
}

Threading and Inheritance

When execution splits into multiple threads, scopes can get easily lost. If 42 was bound for the execution of method X, which kicks off method Y in a separate thread and then finishes its own execution, should 42 be unbound? Hard to say when we don't know whether Y is still busy and might try to read the value later. So, by default, scoped values provide thread isolation and calling get from a different thread than the one that bound a value won't work.

	ScopedValue
		.where(ANSWER, 42)
		.run(this::x);
//	               │
//	               ↓
	new Thread(this::y).start();
//	               │ │
//	scope x ends <─┘ │
//	 └> unbind 42!   │
//	                 ↓
//     ~> NoSuchElementException
	           ANSWER.get();//💥
//	(even if x is still running)

But there's an exception to this scoping issue and that's the structured concurrency API. It also hinges on scopes, namely that when a task splits into concurrent subtasks / threads, their completion is awaited and their results are collected in the same scope while the parent thread waits. Or, in other words, the child threads' scopes are entirely contained in the parent thread's scope.

	                                     //      ⋮
	                    // parent thread's scope ┤
try (var scope = new StructuredTaskScope //      │
		.ShutdownOnFailure()) {         //      │
	                // child threads' scope ──┐  │
	// fork subtasks                          │  │
	var task1 = scope.fork(this::task);  //   │  │
	var task2 = scope.fork(this::task);  //   │  │
	var task3 = scope.fork(this::task);  //   │  │
	                                     //   │  │
	// wait for completion               //   │  │
	scope.join().throwIfFailed();        //   │  │
	                                     // ──┘  │
	// collect results                   //      │
	var result = task1.get()             //      │
		+ task2.get()                    //      │
		+ task3.get();                   //      │
	IO.println(result);                  //      │
} catch (Exception ex) {                 //      │
	// handle errors                     //      │
	throw new RuntimeException(ex);      //      │
}                                        //      │
                                         //      ⋮

And that's perfect! It means that all scoped values the parent thread has access to can be inherited to the child threads and indeed that's exactly how scoped values and the structured concurrency API interoperate.

ScopedValue.where(ANSWER, 42).run(() -> {
	try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
		// fork subtasks: CAN READ `ANSWER`
		var task1 = scope.fork(ANSWER::get);
		var task2 = scope.fork(ANSWER::get);
		var task3 = scope.fork(ANSWER::get);

		// wait for completion
		scope.join().throwIfFailed();

		// collect results: 3*42
		var result = task1.get()
			+ task2.get()
			+ task3.get();
		IO.println(result);
	} catch (Exception ex) {
		// handle errors
		throw new RuntimeException(ex);
	}
}

So, TL;DR:

in general, data in a scoped value is only accessible from the thread which bound it
but, if the structured concurrency API is used, the data is automatically inherited to the threads it forks

vs Thread Locals

If you have ever used ThreadLocals, much of this will seem familiar to you. They, too, allow transmitting data without passing arguments and they, too, provide thread isolation. In fact, at first glance, their use seems very similar:

create a ThreadLocal variable that is usually private, static, and final
then set data
execute code that can get that data
and make use of the fact that data is isolated per thread

static final ThreadLocal<Integer> ANSWER = new ThreadLocal<>();

void main() {
	ANSWER.set(42);

	// prints "42"
	IO.println(ANSWER.get());

	new Thread(() -> {
		// prints "null"
		IO.println(ANSWER.get());
	}).start();
}

Beyond these similarities, there are a number of crucial differences, though:

All code with access to the ThreadLocal can both read and write data, which allows for complex data flow between callers and callees. To keep code readable, that's best avoided, though, and indeed this isn't frequently used - yet, when reading ThreadLocal code, you can never be sure and need to check carefully. Scoped values make this much easier as there's no question to whether data flows both ways - no, it can't.

static final ThreadLocal<Integer> ANSWER = new ThreadLocal<>();

void main() throws Exception {
	ANSWER.set(42);
	// prints "42"
	IO.println(ANSWER.get());

	doTask();

	// prints "63"
	IO.println(ANSWER.get());
}

void doTask() {
	ANSWER.set(63);
}

My earlier explanation of ThreadLocal's API flow left out an essential step: removing the data when it is no longer needed. In fact, developers using this API also occasionally forget it, which can lead to performance and security issues as data can then be visible to entirely unrelated code that happens to run on the same thread. And when not forgetting removal, sufficiently complex use of thread local's API can just make it really hard to get right. None of this is an issue with scoped values as the clearly defined scope allows the API to automatically remove the data when it's no longer needed.

static final ThreadLocal<Integer> ANSWER = new ThreadLocal<>();

void main() throws Exception {
	ANSWER.set(42);

	// prints "42"
	IO.println(ANSWER.get());

	// remove data
	ANSWER.remove();

	// prints "null"
	IO.println(ANSWER.get());
}

As the name suggests, thread locals isolate data per thread, but, if you want to, you can also use them to pass data from one thread to another by using an instance of InheritableThreadLocal instead. Then, if one thread launches another, the thread-local variable is copied and the new thread starts by reading the same data. But if a thread launches a lot of threads like this, these copies pile up and can consume a sizeable amount of memory. Scoped values' one-way data transmission makes copies unnecessary, so they scale really well with lots and lots of threads.

static final ThreadLocal<String> QUESTION = new ThreadLocal<>();
static final ThreadLocal<Integer> ANSWER = new InheritableThreadLocal<>();

void main() throws Exception {
	QUESTION.set("???");
	ANSWER.set(42);

	new Thread(() -> {
		// prints "null"
		IO.println(QUESTION.get());
		// prints "42"
		IO.println(ANSWER.get());
	}).start();
}

And it was mainly that last point that triggered the development of the scoped values API because virtual threads allow orders of magnitude more threads and so thread locals' memory issue becomes more pressing. But note that virtual threads and thread locals do work together correctly, so it's not like you need to refactor from thread locals to scoped values. You may want to for readability, though. In fact, scoped values should be your default for this kind of use case. Only use ThreadLocal for the dirty cases: when you really need two-way data transmission or unscoped life-time for your global state.

(Gasp! Oh, great gasp, everyone. Bravo!)

Finalization

The structured concurrency and scoped value APIs are both in their fourth preview in JDK 24. Structured concurrency will probably see a slight revamp and another preview in 25, but scoped values seem to be stable and they may finalize. We'll find out more about that once Java 24 gets released in two and a half weeks at JavaOne - something we'll live stream on this channel, by the way; link to more details in the description. Following that, OpenJDK will turn towards 25 and I expect new JEPs to be filed soon after. As always, you'll learn all about that here, so subscribe if you haven't already and leave a like to help us spread the word. So long ...

Watch the video.

JDK 24 Deprecates Remote Debugging with jstat And jhsdb For Removal

Nicolai Parlog — Fri, 31 Jan 2025 00:00:00 GMT

Due to their reliance on RMI, which the JDK is moving away from, the remote debugging capabilities of jstat and jhsdb are deprecated for removal

Moving Away From RMI

Java's Remote Method Interface (RMI) was introduced in 1997 to allow transparent remote procedure calls from one Java Virtual Machine to another. It uses serialization to encode objects as bytes when transporting them as arguments and return values between JVMs. Both technologies have long-term security concerns and configuration difficulties and did not stand the test of time. Today, the wider ecosystem has replaced RMI with more web friendly protocols and so Java itself is also reducing and removing dependencies on it where possible.

Local Measurements and Debugging

Among other tools, Java offers these two to connect to a local HotSpot JVM and observe or debug it as well as the program it executes:

jstat reads performance counters
jhsdb provides snapshot debugging and analysis features

Both tools' capabilities for local use remain in place and there are no plans to change that.

Remote Use Deprecated for Removal

Both jstat and jhsdb offer remote capabilities, which are implemented using RMI. Due to the aforementioned effort to reduce dependencies on RMI, jstat's and jhsdb's remote capabilities are deprecated for removal:

jstatd (allows remote connections with jstat) - JDK-8327793
jhsdb debugd (allows remote connections with jhsdb) as well as the --connect option of the jhsdb subcommands hsdb and clhsdb - JDK-8338894

Questions or feedback on these deprecations can be directed at the serviceability-dev mailing list.

Alternatives

An alternative tool for getting remote insights into a running HotSpot JVM is the JDK Flight Recorder (JFR).

Java Language Evolution in 2025 - Inside Java Newscast #84

Nicolai Parlog — Thu, 30 Jan 2025 00:00:00 GMT

In 2025, the Java language keeps evolving. Here's how Project Amber plans to push Java forward: from flexible constructor bodies to simplified main, from module imports to primitive and deconstruction patterns, from withers to string templates.

Welcome everyone to the Inside Java Newscast, where we cover recent (and in this case future) developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna look at Java's plans for language evolution in 2025. Specifically, we check in on what Project Amber will be working on this year as well as a few other explorations that I'm aware of. As last episode about all the other project's plans for 2025:

working on does not mean releasing this year - hope is pain, patience is key
check the description for lots of follow-up links
and check inside.java to track OpenJDK's work as it happens

Ready? Then let's dive right in.

Current Previews

Project Amber's main focus for 2025 will be on finalizing the four features that are currently in preview. I made dedicated videos on each, and not much changed since then, so I'll keep this part brief. Remember, if you want to contribute to Java's development, the best way to do so is to try these preview features in your code base and give feedback on the amber-dev mailing list.

Flexible Constructor Bodies

First up: Flexible constructor bodies allow us to more freely arrange code in the constructor by lifting the limitation that there can be no code before a call to another constructor, regardless of whether the call is explicit or implicit or whether the constructor is in the same class or a super class.

class Name {

	private final String first;
	private final String last;

	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

}

class ThreePartName extends Name {

	private final String middle;

	ThreePartName(String full) {
		// split "first middle last"
		// on space
		var names = full.split(" ");
		this.middle = names[1];
		super(names[0], names[2]);
	}

}

This started out with the intent to make the language more flexible but turned out to come in extremely handy for Project Valhalla's exploration of null-restricted types. If a field is restricted to a non-null User instance, for example, then what should be its initial value? Can't be null since the field should not contain that. What other instance could it be? But what if it actually is null, but the language guarantees that no code ever observes that? That would mean such fields would have to be assigned before a super constructor is called and there's the connection between flexible constructor bodies and Valhalla.

class ThreePartName extends Name {

	// String! <-> "non-null String"
	private final String! middle;

	ThreePartName(String full) {
		var names = full.split(" ");
		this.middle = names[1];
		// super class can't observe
		// null `middle`
		super(names[0], names[2]);
	}

}

While there was no change to this feature between its preview in JDK 23 and 24, I personally wonder whether it will stay in preview until Valhalla's requirements are more well-understood. If you can make it to California in the third week of March, come to JavaOne and hear it from the horse's mouth - JEP owner Dan Smith will give a talk on exactly this topic.

Simplified Main

Next up are simple source files and instance main methods, which have seen quite the churn in its four previews and I think more changes are on the horizon regarding the details of the new IO class that makes printing to and reading from the terminal simpler. I really wish this feature would finalize in JDK 25 because it is the next release with long-term support by Oracle and other vendors, but as I've said in the past, OpenJDK doesn't really care about that and so it very well may not.

// complete source file
void main() {
	IO.println("Hello, World!");
}

Module Imports

Then we have the super convenient module imports, which are quickly becoming my favorite feature when working outside an IDE. import module java.xml (or whatever) imports all public types in exported packages from that module and is thus very comprehensive, super concise, and easy to read. I'm honestly starting to wonder whether I should use them in real-life, IDE-based projects, too. What do you think? Are module imports "only" better than star imports or also better than importing each type on its own? I'm not aware of any changes coming down the line for module imports.

Primitive Patterns

And finally we have primitive patterns, meaning being able to match on primitive types, for example when deconstructing a record.

record Point(long x, long y) { }

var point = new Point(/* 🤷🏽 */, 0);
var xType = switch (point) {
	case Point(byte x, _) -> "Byte: " + x;
	case Point(short x, _) -> "Short: " + x;
	case Point(int x, _) -> "Integer: " + x;
	case Point(long x, _) -> "Long: " + x;
};

This mostly just rebalances the language by allowing us to use primitive types more like reference types in such situations but it also has the very nice effect of allowing us to quickly check whether a number can be losslessly represented by another numeric type. Very useful, particularly when floating point numbers are involved due to potential loss of precision.

jshell> boolean is216float = 16_777_216 instanceof float
        is216float ==> true
jshell> boolean is217float = 16_777_217 instanceof float
        is217float ==> false

This preview also seems pretty stable, so I'm hoping it finalizes this year but Pattern Progenitor Angelos Bimpoudis can give you more insights on that at JavaOne.

So, here we have the four preview features that Amber will be pushing forward this year but since they probably won't radically change, that leaves some time for explorations into yet newer features, some of which we may well see become a JEP this year - let's take a look.

Further Explorations

Deconstruction

A key feature that Amber is currently working on is deconstruction. As you know from using pattern matching, record instances can be easily deconstructed into their constituting components. And as we'll see in a minute, this capability goes way past pattern matching, but for now let's consider broadening it - why limit it to records?

record Point(long x, long y) { }

Object obj = // ...
var objString = switch (obj) {
	case Point(long x, long y) -> x + " / " + y;
	default -> obj.toString();
};

Clearly, there are many classes that do much more than hold data or that want to encapsulate their internals and thus shouldn't be deconstructable. And that's all good, nobody's saying that that needs to change. But there are other classes whose instances do mostly hold data and who don't need to encapsulate all of it and those would benefit from deconstruction. Imagine a class could, optionally, define a deconstructor that splits an instance into a bunch of values, I guess those would typically reflect some or all of its fields. Then we could use those classes in pattern matching as well as in the other features I'll get to momentarily.

class PointOnX {

	private final long x;

	public Point(long x) {
		this.x = x;
	}

	// MADE-UP SYNTAX !!
	public deconstructor(long x) {
		x = this.x;
	}

}

Object obj = // ...
var objString = switch (obj) {
	case Point(long x, long y) -> x + " / " + y;
	case PointOnX(long x) -> x + " / 0";
	default -> obj.toString();
};

Now, "shouldn't those classes be records in the first place?" you might wonder. And you'd actually be on the right track here. Such classes do probably want to be records and may even have started out as one, but then a requirement popped up that just doesn't align with record limitations. Maybe a field needs to be reassigned or some computation needs to be cached. It makes sense that such requirements don't allow a class to be a record, but it makes much less sense that they then also can't be deconstructed. With custom deconstructors you not only have more freedom to pick the kind of type that best fits your situation, you'll also be able to refactor from a record to a class without breaking all code using your type - similarly to how you can refactor from enum to class, by the way.

So this is something Amber is quite busy with at the moment and it will open the door to a bunch of cool follow-up features.

Withers

One of them are withers, which I made a whole video about that I don't want to repeat here. Cliff's notes are that a with expression deconstructs an instance into variables, let's you reassign their values, and then calls a constructor with them, thus giving you a new instance that is mostly the same as the old one except for the changes you made.

record Point(int x, int y) { }

var point = new Point(24, 42);
// syntax proposed by JEP 468
var pointZeroY = point with {
	y = 42;
};

Since this builds on deconstruction and that's not yet settled for classes, it makes sense to explore these features in unison and my guess is that we won't see a withers preview before a preview for class deconstruction.

More Patterns

We've also heard about deconstruction on assignment, meaning that instead of assigning the results of a method call or another expression to a variable and then in following statements pulling out the values we need, we may be able to deconstruct immediately and only keep around what we want. Obviously, this also builds on deconstruction.

And then there are custom patterns, which seem unrelated to deconstruction but can also be seen as a superset of them. When deconstruction says "without arguments and unconditionally, return this bunch of values", then a custom pattern would say "given these arguments if a condition is met, return this bunch of values". For example "given a key, if this map contains it, return the respective key-value pair".

So both of these are kinda blocked by deconstruction and I'm pretty sure are at best tertiary considerations at this point. But we'll be getting there sooner or later, unlikely in 2025, though... so why am I talking about them here? I think I nerd-sniped myself. Eh, doesn't matter - string templates!

String Templates

The string template preview was pulled because it didn't quite hit the spot. Again, whole video on that, short version is that the extra syntax it proposed didn't pull its weight and there are probably better ways to achieve the main goal, which is not code golf but a safer way to concatenate strings. I hope to hear more about string templates this year.

Miscellaneous Work

Quick lightning round about three other explorations I'm aware of:

Viktor Klang made the questionable decision to make serialization 2.0 his project, which is why we dubbed it Klang marshalling. To his dismay, I might add, which just motivates me further to make this a thing. The idea here is basically withers turned all the way to 11 where, after deconstructing a whole tree of suitable instances, instead of reassigning values, they're dumped into a data-transfer format (be it binary, JSON, or whatever) before later being reconstructed from there. Importantly: no magic needed; just the aforementioned deconstructors and then regular constructors. Viktor will be giving an update on this at JavaOne.
Then, Per Minborg is working on so-called "stable values", an API that allows lazy initialization of values that will afterwards be treated as final by the JVM, which improves maintainability and performance. This JEP came out of draft last week and we'll take a closer look at it here soon but Per will also present it at JavaOne.
And last and least specific on this list is Stuart Marks' and Kevin Bourrillion's exploration of sets and equals. The core issue is that set membership is defined on the basis of equals but some kinds of sets would prefer something else, for example a comparator or a custom "equals-checker" to determine membership. This is a tricky one because it involves the specification and a whole lot of code that relies on it but if anybody can pull this off, it's Stuart and Kevin.

That's it from me, Ana will be there in two weeks talking about quantum encryption, so I'll see you again in four. So long...

Watch the video.

Java's Plans for 2025 - Inside Java Newscast #83

Nicolai Parlog — Thu, 16 Jan 2025 00:00:00 GMT

In 2025, Java keeps evolving. Here's how the big OpenJDK projects (Leyden, Valhalla, and more) sans Amber plan to push Java forward.

Happy Gregorian new year, everyone, and welcome to the Inside Java Newscast, where we cover recent (and in this case future) developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about Java's plans for 2025 or, more specifically, what the big OpenJDK projects except Amber will be working on this year.

"Why 'except Amber'?" I cannot hear you ask. Because, just like with the JDK 24 feature set, OpenJDK keeps being too productive for this show's format (kinda disrespectful if you ask me) and so I have to make another two-parter and Amber, plus a few miscellaneous developments that I'm aware of, will take up the whole second episode in two weeks!

Before we get started with this episode, I need to do a bit of housekeeping:

I'll talk about what features these projects will work on this year but that by no means implies that they're gonna be released this year, so let's be patient.
But if you want to speed things along, you actually can: Find a feature that interests you and is in some form of preview, try it out in anger, and give feedback - a bit more on the importance of that later.
If you want to follow these developments along, make it a habit to check in on inside.java, where we publish updates as they appear.
And of course, there are links to all projects, mailing lists, and everything I mention in the description.

Ready? Then let's dive right in.

Project Babylon

Project Babylon's primary goal is to extend the reach of Java to foreign programming models such as SQL, differentiable programming, machine learning models, and GPUs. Babylon will achieve this with an enhancement to reflective programming in Java, called code reflection.

The code reflection prototype is available in the project's repo and is currently being carefully refactored to prepare for an eventual incubation. Its further development is mainly being pushed by the ongoing work on HAT, the Heterogeneous Accelerator Toolkit, which offers an NDRange-based GPU programming model with idioms that are familiar to GPU developers. Babylon is also exploring an ONNX-script-equivalent (of course in Java) - at this point mostly just to prove that it can be done. And I heard rumors that there's a chance (no promise!) that project lead Paul Sandoz can present a prototype at JavaOne in March.

Oh right, did I tell you that JavaOne is back? (Again.) Redwood Shores in the Bay Area, USA, March 18th to 20th. Meet Paul, Brian Goetz, and many other OpenJDK leads and contributors. Tickets still available - link in the description.

Code reflection, HAT, ONNX - all of this is still pretty early, though. If you want to get a better understanding of the current state, I'll link two fairly recent emails (1, 2) with progress reports in the description. You can also check out these three talks from the JVM Language Summit in August 2024:

Paul presented an update on code reflection
and another on HAT, including a live-demo of computing the Game of Life on a GPU - very courageous
Intel's Steve Dorhmann presented on how to translate Java to SPIR-V

There are also some articles, including one about neural networks with Triton and another about emulating C#'s LINQ, again both from Java of course. Lots going on in Babylon, the tower is getting taller.

Project Loom

After finalizing virtual threads in 2023, Project Loom removed the biggest hurdle to straightforward adoption in 2024: pinning of virtual threads when interacting with object monitors, which means no more pinning on synchronized blocks and on Object::wait. This will be shipped with JDK 24 in March.

The highest priority for 2025 is progress and hopefully finalization of the two preview APIs Loom has in the fire:

structured concurrency for a simplified concurrent programming model that treats groups of related tasks running in different threads as a single unit of work for a host of benefits over other threading models
scoped values, which can be summarized as an improved and more virtual-thread-friendly variant of thread locals

The team is still looking for more feedback on these, particularly on the structured concurrency API, which will in all likelihood see a slight revamp in the next preview in JDK 25. If you have the chance, please try these APIs and report back to the Loom mailing list.

Java developers frequently ask me how they can contribute back to OpenJDK and while most are thinking about writing code, an easier and much more valuable way to contribute is this - trying out previews in as close to a production environment as possible and reporting the results back to the respective projects. Every project lead I talked to for this video asked me to ask you for more feedback. To put it bluntly: What makes your contribution unique isn't that you can code (the OpenJDK folks are kinda decent at that), it's that you can report real-life outcomes of putting new features into practice - that's much harder to achieve for OpenJDK in a matter that represents all niches of Java's gigantic ecosystem.

Beyond the structured concurrency and scoped values APIs, there's also work on less-impactful pinning issues and lock information in thread dumps.

Project Leyden

Ahh, it feels like only yesterday that we watched Project Leyden gurgle its first word (it was "condenser", by the way) and in just two months we can already use its first feature in production, namely ahead-of-time class loading and linking. They're growing up so fast. Again, if you have the chance, please kick the tires and report back, particularly your experience with training runs.

As for 2025, there two features in the pipeline that will be worked on, namely ahead-of-time method profiling and code compilation. Very early JEP drafts exist for both and I can't wait for them to stabilize - once that happens we'll of course take a closer look at it here.

Project Lilliput

Project Lilliput aims to reduce the memory consumption of object headers by shrinking them from 12 or 16 bytes on 64-bit systems to 8 bytes, with a stretch goal of just 4 bytes, which would free up 10-20% of the heap. JDK 24 will ship with experimental compact object headers of 8 bytes that you can put through the ringer and report your findings.

The main task for 2025 is to evaluate in practice the performance as well as the imposed limit on the number of classes. This limit stems from the fact that each object header contains a so-called class pointer, which references a data structure describing the object's type, for example its field layout. With fewer header bits, that pointer had to shrink to 22 bits, meaning a maximum of four million classes. Sounds plenty, but keep in mind that some libraries and frameworks generate classes at runtime, which may make some applications surpass that limit.

Beyond that, there are also some implementation details to iron out. The goal of all this work is to make compact object headers non-experimental and eventually the default.

Project Panama

Project Panama has three irons in the fire:

First, the vector API. It's very stable for now and some projects already use it in production but its finalization is still waiting for Valhalla. You might've heard me say that it's waiting for universal generics, specifically, but it looks like I was wrong about that. Instead it's about identity and specification: It's important for the API's performance that vectors lack identity, which is currently achieved by bespoke optimizations in HotSpot but without value types, this behavior is unspecified. So once Valhalla's JEP 401 starts the preview on value types, the vector API can lean on that and itself go from incubating to preview, which will include a thorough re-review of the API that may result in further changes. If you've used it and found some operations missing or any other issues with it, please take it to the Panama mailing list.

Second, the foreign function and memory API was finalized in JDK 22 and has been very well received. Since then, the project's focus has shifted to improving performance, specifically by making memory access as fast as possible across the board and by reducing the startup and warmup time from the use of method and variable handles. They're also working on record mappers, which allow user-friendly and performant mapping between native memory segments and Java abstractions such as records and interfaces. The core functionality is coming along well and various ways to express it are currently being explored.

And third, there's jextract, the tool that generates FFM bindings from native library headers. The main focus there is to try and take advantage of the StableValue API to emit simpler bindings with fewer side classes. Stable values are still in development and don't technically live under Panama's roof, but they visit often to hang out with their cool aunt. I'll get to StableValues in the next video.

Project Valhalla

Before going into the tech, we need to talk about the "Valhalla, when?" comments that pop up under every video on this topic and quite a few others. Love 'em, keep 'em coming. Every time I see one, I forward it to Brian and I'm really happy that German labor laws protect me.

Ok, so Project Valhalla short and sweet:

JEP 401's value types preview has become the tip of the spear and the main focus is on getting it out to you.
A somewhat surprising runner-up is the development of null-checked types - like String! and String? - also sometimes called emotional types, presumably not because they make people emotional even though they definitely do.

Check out this talk by Brian to learn more about that - the link in the description is time-stamped to the respective chapter. 3. Some early explorations of improved numerics and primitives layered on top of value classes.

That leaves us with only one question: Valhalla...

Watch the video.

Java 24 Performance Improvements & Deprecations - Inside Java Newscast #82

Nicolai Parlog — Thu, 12 Dec 2024 00:00:00 GMT

Java 24's feature list contains a whopping 24 JDK Enhancement Proposals. Here, we're going to look at the performance improvements and deprecations/removals.

JDK 24 also ships with a bunch of performance-related improvements:

ahead-of-time class loading and linking

virtual threads now synchronize without pinning

Shenandoah and ZGC further embrace the generational hypothesis

G1 got a late barrier expansion

compact object headers

full JDK runtime images can be a bit smaller

But more details on all of in the next Inside Java Newscast, next week.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and after we've looked at JDK 24's language and API changes last week, today we're gonna go over its performance improvements and also all the things JDK 24 deprecates and removes. I gotta warn you, though, Billy contributed some sections to this video and they're... well, let's, just like him say they're special.

Reduced JDK Size

Wow Nicolai, that's a very nice compliment! Allow me to send you this package with a gift inside, in appreciation. But that reminds me about packaging the JDK.

So, all Java developers can appreciate reducing the size of their container images, especially when shipping Java applications in a cloud environment. JEP 493, Linking Run-Time Images without JMODs, helps reduce the disk space size of the JDK binary, by allowing it to be shipped without the need to include JMODs. Now, this is a process that would happen while building the JDK, so not something Java developers would typically perform, though I suppose you could build the JDK yourself, if you so desire. This is an optional process, so some JDK vendors will continue to include the JMOD files, but whether the JMOD files are present or not, your experience using jlink to build custom runtime images should remain the same.

If you would like to learn more about using jlink to build custom runtime images, you can check out this video. And also be sure to check out JEP 493 for additional details, links in the description. Now I need to send my gift to Nicolai.

Synchronize Virtual Threads without Pinning

See what I mean? Anyway, let's focus on the topic at hand: Before JDK 24, when a virtual thread entered a synchronized method or block, it would get pinned, meaning it wouldn't unmount in situations where it otherwise would, which would lead to a valuable carrier thread getting blocked. That's not good and after a lot of work on object monitors, the mechanism underpinning synchronized as well as Object::wait, these operations no longer pin virtual threads. So if you have tried them before but were underwhelmed by their effect, that may well have been because your project happens to have a lot of blocking operations inside synchronized blocks, in which case you should see much better scalability on JDK 24. This is great as it removes the main hurdle for just straightforward adoption of virtual threads.

Generational Garbage Collection

Oh, hey there, so I'm about to take out this garbage out to be collected in a dumpster. But you know what, that reminds me about garbage collection in Java.

Ok, so in JDK 24 there are two noteworthy changes happening. In JEP 404 (if you can find it), Generational Shenandoah is being added as an experimental feature. If your JDK supports Shenandoah, you can enable Generational Shenandoah by enabling experimental features, and setting Shenandoah's GC mode to generational, exact commands on screen:

-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

If you would like to learn more about Generational Shenandoah check JEP 404 as well as Shenandoah's wiki.

Continuing on garbage collector news, Non-Generational ZGC was deprecated in JDK 23 and set to be removed in JDK 24, leaving Generational ZGC as the only option when using ZGC. If you would like to learn more about Generational ZGC, you can check out my hands on video (here) as well as this video from Erik Osterlünd at JVMLS.

Ok, I need to go take care of this trash, back to you Nicolai in the studio!

Late Barrier Expansion for G1

Oh, hey there, I was just about to write Billy what I think of his garbage joke to introduce the topic of garbage collection, but you know what, that reminds me of the topic garbage collection. So, Garbage collectors need to keep track of quite a few pieces of information and one way they do this is with so-called write barriers. A write barrier is a piece of code that does extra work on every reference store, for example to keep track of objects in the old generation referencing ones in the new generation or of objects in one region referencing ones in another. Being a regional garbage collector, G1 has rather complex barrier operations, and it's the just-in-time compiler's job to make sure they run as fast as possible.

To that end, C2 used to expand G1's barriers early in its pipeline since that would give it more chances to optimize it in later steps. However, it turns out that G1's barrier operations don't optimize well and so the early expansion causes additional work for very little benefit. ZGC was in a similar position a few years ago and adopted a late barrier expansion instead and now G1 does the same in JDK 24. This considerably reduces the amount of work the JIT has to do - for the combination of G1 and C2, the savings can be as much as 10-20% of the JIT's work, so you should see a slight performance improvement on JDK 24.

Experimental Compact Object Headers

Imagine your heap space: A big chunk of memory, usually in the gigabytes, that your instances live in. The strings and collections, the data-transfer objects and web services, the customers and orders, all of that. On many workloads, the average object size is 256 to 512 bits, or 32 to 64 bytes, or 4 to 8 words, but not all of that is your data. Usually 2 of each of those words are the so-called "object header" - that's between 20% and 40% of your heap!

What's an object header? Can't we make it smaller? Imagine how much memory that would save us.

And that's exactly what Project Lilliput, JDK Enhancement Proposal 450, and this Inside Java Newscast are all about.

Well, not this Newscast but that old one from May 2023 was all about that. It went into a lot of detail on how object headers work and how Project Lilliput and JEP 450, specifically, propose to reduce their size from 12 or 16 bytes on 64-bit hardware to just 8 bytes, thus saving applications an average of 10-20% heap of memory.

On JDK 24, compact object headers are an experimental feature that, quote:

will have a broad impact on real-world applications. The code might have inefficiencies, bugs, and unanticipated non-bug behaviors. This feature must therefore be disabled by default and enabled only by explicit user request. We intend to enable it by default in later releases and eventually remove the code for legacy object headers altogether.

Compact object headers can be activated with -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. (There, that was easy.) If you have solid performance benchmarks for your application, I highly recommend running them with these options and reporting your results back to the hotspot-dev mailing list. Everybody else, just sit back and relax, and let's wait for this feature to become permanent. And in the meantime, let's check in on Billy.

Ahead-of-Time Class Loading & Linking

I'm reporting from the Arctic where the only thing lower than the temperature... is your startup times with the inclusion of JEP 483! JEP 483, Ahead-of-Time Class Loading and Linking, is the first of the Leyden JEPs to be included in a mainline JDK release. Project Leyden is about reducing startup time, time to peak performance, and memory footprint, though this JEP primarily focuses on startup time. To take advantage of this new feature currently requires a three-step process, though this should be simplified in future releases.

The first step is to set AOTMode to record for a training run and providing the name of an AOTConfiguration file, where the data from that training run is stored.
Step two is setting AOTMode to create, the name of the AOTConfiguration from the first step, and the name of the AOTCache to be created.
And then finally, step three, is providing the AOTCache that was created and basking in the lower start up times in production.

In the JEP, they talk about how using the AOT cache reduced the startup time of the Spring PetClinic application by between 33 and 42%. They also provide details on how to run a training run, but the most important part is: The closer your training run matches production behavior, the more benefit you will see.

Now, if you are watching this video a little bit in the future, I will be releasing a video that deep-dives into JVM startup, which also covers class loading and linking. So if you interested in learning about that subject, that video link will appear here, but you can also consider subscribing and turning on notifications so you will be notified when that video is released. Also be sure to check out the JEP which provides additional details on this feature. Ok Nicolai is going to talk about more integrity by default while I go warm up.

More Integrity by Default

Thank you Billy, for blowing our entire special effects budget on that "startup time is lower than arctic temperatures joke" - totally worth it. That completes the performance part, now let's talk about deprecations and removals in JDK 24.

The Java platform makes a lot of promises, from type safety to its memory model, from visibility modifiers to finality, but they all hinge on one core property: integrity - the guarantee that the platform upholds the promises it makes. At the same time, Java offers a bunch of mechanisms that can undermine this integrity: Reflection can sidestep visibility and finality, Unsafe can corrupt memory, and native code can easily straight-up crash the JVM. Under this tension, Java is currently developing a principled stance: integrity by default. Operations that can undermine integrity are either replaced by alternatives that cannot or will be disabled by default to be enabled on demand by applications operators if they deem the tradeoffs beneficial. And JDK 24 is taking further steps down that road:

The memory-access methods on sun.misc.Unsafe, that were deprecated for removal in JDK 23, will now issue a warning on first invocation. This behavior can be configured with the command-line option --sun-misc-unsafe-memory-access, which accepts values allow (the default in JDK 23), warn (the default on 24), debug for more information, and deny. And I highly recommend to run your app with deny to prepare for a future where it will be the default before the entire option is eventually removed together with those methods on Unsafe.

The foreign function and memory API used to require the command line flag --enable-native-access to allow execution of so-called restricted operations - those that can undermine integrity. JDK 24 temporarily downgrades a lack of that option from error to warning, so that it can onboard the Java Native Interface, which used to just allow access to its potentially troublesome operations. Now both APIs contribute to the list of restricted operations, access to which is uniformly managed with two options: Use --enable-native-access to allow access for specific code and use --illegal-native-access to configure how code that didn't get the green light should be handled. That last one will get stricter over time with denying such access being the inevitable default.

Disabled Security Manager

Back in the day, when Java applications routinely or at least occasionally ran untrusted code, for example user-provided plugins to a desktop application, the security manager seemed like a reasonable way to securing such apps. If enabled, it operates under the principle of least privilege, meaning code is untrusted by default and cannot access the filesystem, the network, or other such resources unless explicitly allowed. On the JDK side that means that over 1,000 methods must check for permissions and over 1,200 methods must elevate their privileges. On the user side that means that an active and effective security manager requires careful navigation of its complex permission scheme.

While that may have been worth it for a decent chunk of Java applications in the past, the evolution from desktop apps to server-side code and the security features of modern operating systems, containers, and cloud environments, eroded that need to the point where security manager use is exceedingly rare. But its maintenance burden remained and so in 2021, OpenJDK decided to phase out the security manager by deprecating it for removal in JDK 17.

Now, JDK 24 takes the next step and permanently disables it:

setting the option java.security.manager to any value except disallow will lead to an error
calling System::setSecurityManager will throw an UnsupportedOperationException

A few more options are impacted, but, importantly, the class SecurityManager as well as related methods remain for now, but are changed to have no effect, for example by doing nothing, returning false, etc. If your project uses the security manager or even if you're not sure about it, please check out JEP 486 for a lot more details on the motivation, the current process, and future work.

Bye, Bye 32-bit x86

The time of 32-bit x86 is coming to an end. No new such hardware is being manufactured, the last Windows OS that supports it will reach End of Life in less than a year, and Debian announced a year ago that they'll soon stop supporting it, too. Accordingly, OpenJDK is winding down its support for 32-bit x86: The respective Windows port was deprecated in JDK 21 and is being removed in JDK 24 and the respective Linux port is deprecated in JDK 24 with the plan to remove it in 25. This frees up development time within OpenJDK that used to be spent on implementing 32-bit variants of or even workarounds for more involved features like virtual threads or the FFM API.

Note that this has no implications for 32-bit x86 ports of older JDK versions. So if you're planning to run JDKs like 8 or 21 on 32-bit hardware for a few more years, that's fine. It's just that once you move to JDK 25, you'll very likely be forced to run that on 64-bit hardware.

And that's it for JDK 24 as well as for the Inside Java Newscast in 2024. I hope you had a good time, we here at the Java Platform Group surely did. We wish you all the best for the upcoming holiday weeks if you have some time off, and we'll see you again in 2025. So long ...

Watch the video.

JDK 24 Prepares Restricted Native Access

Nicolai Parlog — Mon, 09 Dec 2024 00:00:00 GMT

JEP 472 prepares restricted access to native code through JNI and the FFM API

Native Access and Integrity by Default

Any interaction between Java code and native code, be it via the Java Native Interface (JNI) or the Foreign Function & Memory API (FFM), is risky in the sense that it can compromise the integrity of applications and of the Java Platform itself, for example by causing JVM crashes, even after the native code completed execution. According to the policy of integrity by default, all JDK features that are capable of breaking integrity must obtain explicit approval from the application's developer. JDK 24, by means of JEP 472, prepares that by aligning the behavior of JNI and FFM by:

printing warnings for all restricted operations (with the goal to turn these into exceptions in a future release)
expanding the command-line options --enable-native-access and --illegal-native-access to govern restricted operations of both APIs

Note that the intent is neither to discourage the use of, deprecate, or even remove JNI nor to restrict the behavior of native code called via JNI or FFM. The goal is to ensure that applications and the Java Platform have integrity by default while giving application operators the tools they need to selectively opt-out where needed.

Restricted Operations

These JNI operations are considered restricted:

calls to System::loadLibrary, System::load, Runtime::loadLibrary, and Runtime::load
declaration of a native method

These FFM operations are considered restricted:

AddressLayout::withTargetLayout
Linker::downcallHandle
Linker::upcallStub
MemorySegment::reinterpret
ModuleLayer.Controller::enableNativeAccess
SymbolLookup::libraryLookup

The documentation contains an always up-to-date list of all restricted methods.

Enabling/Disabling Restricted Operations

Executing restricted operations will, by default, cause output like the following on the standard error stream:

WARNING: A restricted method in java.lang.System has been called
WARNING: System::load has been called by com.foo.Server in module com.foo (file:/path/to/com.foo.jar)
WARNING: Use --enable-native-access=com.foo to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Note that this is a change for JNI, which used to not trigger such warnings, as well as for FFM, which used to forbid restricted operations by default. Starting with JDK 24, both APIs behave uniformly by printing warnings - in the future, both will throw exceptions instead. You can configure this behavior with the two command line options --enable-native-access and --illegal-native-access.

The option --enable-native-access=$value enables access to all restricted operations for either the entire class path (if $value is ALL-UNNAMED) or the listed modules (if $value is similar to com.mod1,com.mod2). This is the intended and long-term supported way to enable access to restricted native operations.

If native access is not enabled via that option, it is illegal for code to perform restricted operations. The new option --illegal-native-access=$value determines how the Java runtime handles such cases, depending on $value:

allow: allows the operation
warn: issues warnings as described above (this is the default in JDK 24)
deny: throws an IllegalCallerException

In a future release, deny will become the default and allow will be removed. Similar to --illegal-access, which was introduced in JDK 9, setting this option to values below the default (e.g. to allow on JDK 24) should be considered a short-term fix until the correct use of --enable-native-access is established. Also similar to --illegal-access, --illegal-native-access can be used to prepare a project for a future, stricter Java release.

The recommended way to run applications that use JNI or FFM on JDK 24 is:

java --enable-native-access=$value --illegal-native-access=deny ...

Here, $value is ideally a list of names of modules that access restricted operations, otherwise ALL-UNNAMED if such code resides on the class path.

To help identify libraries that use JNI, a new JDK tool, tentatively named jnativescan, statically scans code in a provided module path or class path and reports uses of restricted methods and declarations of native methods. If you want to track (un)loading of native libraries, observe the JDK Flight Recorder events jdk.NativeLibraryLoad and jdk.NativeLibraryUnload.

For more details, please read JEP 472 and check JDK-8324665.

Java 24 Language & API Changes - Inside Java Newscast #81

Nicolai Parlog — Thu, 05 Dec 2024 00:00:00 GMT

Java 24's feature list contains a whopping 24 JDK Enhancement Proposals. Here, we're going to look at the language and API changes.

It's the time of the year again, where OpenJDK forks the next Java release off of the main development branch, thus freezing its feature development. And it's high time it did that, because an unprecedented but fitting 24 JDK Enhancement Proposals have made it into the JDK 24 code base, way too many to cover in one Newscast. How dare them not considering this YouTube show when picking JEPs?!

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna go over the first half of the changes JDK 24 brings to Java. Specifically, we're gonna look at language and API changes; next week it'll be performance improvements and deprecations/removals. Ready? Then let's dive right in!

JDK 24 Early-access builds

Stream Gatherers

The JEP 485 is about adding a new feature to the Stream API called the Gatherer API. It gives you three elements: an interface, a method on the Stream interface that takes a Gatherer as a parameter, and a factory class called Gatherers, with pre-made gatherers. Imagine that you need to implement a distinct()-like behavior, but with your own way to compare object for equality. Like comparing strings of characters, ignoring case differences. You can map your strings to lower case, store them in a HashSet within your gatherer, and if they are not already in this HashSet, push the original element to the downstream. A gatherer works on four elements: a mutable state, an integrator, a finisher, and a combiner. They can be integrated in parallel streams, even if they do not themselves support parallelism.

Better Java Streams with Gatherers - JEP Cafe #23

Class-File API

Another API that got finalized in JDK 24 is for reading and manipulating bytecode. While few developers do that directly, most projects do it indirectly, and a lot. Whether to analyze code and dependencies, inject aspects or performance counters, generate proxies or avoid reflection at runtime, there are plenty of ways to employ bytecode manipulation for the greater good. The issue is that this requires libraries, like ASM, that understand Java's bytecode and since that can evolve from release to release, we end up in a situation where releases of those libraries don't work with JDK versions that were released later. This is a big contributor to the need to upgrade dependencies when upgrading the JDK, which isn't the end of the world, but it's not great either. By adding an API to read and manipulate bytecode to the JDK, all the use cases I just mentioned can code against that, which makes them much more robust against breakage from JDK upgrades.

With this API finalized in JDK 24, with a bunch of changes over its second preview in JDK 23, by the way, I recommend that all projects that work with bytecode develop a plan how to switch to this new API in the future to help their users more freely choose the JDK version they're running on. That could be done by baselining against JDK 24 or later, a proposition that works particularly well for projects that adopted a tip & tail release model, or by shipping a multi-release JAR that uses the new API on new JDKs.

New Class-File API will make Java Updates easier - Inside Java Newscast #56

Quantum Salad

JDK 24 includes three cryptographic JEPs and I'm not gonna stand here and pretend that I understand them very well. Encryption is already complex enough and it doesn't help that two of those three JEPs (JEP 496 and JEP 497) throw in quantum computing and some kind of modular salad. lettuce lattice lettuce Come January, Ana will go through these changes in a dedicated Inside Java Newscast - for this video, I'll stick to the high level.

To prepare for a future where quantum computers could break encryption algorithms like RSA and Diffie-Hellman, Java is adopting quantum-resistant alternatives. These module-lattice-based algorithms were standardized by the US National Institute of Standards and Technology (NIST) and JDK 24 enables them for key encapsulation and digital signatures by making them available through the KeyFactory, KeyPairGenerator, KEM, and Signature APIs. The new algorithm family is called ML-KEM and ML-DSA, respectively, and using it follows the regular API flow.

var kf_kem = KeyFactory.getInstance("ML-KEM");
var kf_dsa = KeyFactory.getInstance("ML-DSA");

var kp_kem = KeyPairGenerator.getInstance("ML-KEM");
var kp_dsa = KeyPairGenerator.getInstance("ML-DSA");

var kem = KEM.getInstance("ML-KEM");

var sig = Signature.getInstance("ML-DSA");

The two JEPs are final in JDK 24, which already brings us to the end of the list of finalized features for this episode.

You have a choice to make now: You can keep watching for an update on all the language and API previews shipping with JDK 24 or you can subscribe for next week's Newscast, where I'll go over half a dozen performance-related features that JDK 24 comes with. Sorry, what? What's that? Oh. I'm just now being informed that you can also do both. Crazy times. Dogs and cats, living together!

Key Derivation Function API

The third cryptographic JEP first previews an API for key derivation functions; KDFs. KDFs follow JDK 21's key encapsulation mechanism as a second step towards Hybrid Public Key Encryption, which enables the smooth transition to quantum-safe encryption algorithms. KDFs, and let me read from the JEP here, ...

make use of cryptographic inputs, such as initial key material, a salt value, and a pseudorandom function, to create new cryptographically strong key material. A KDF is often used to create cryptographic data from which multiple keys can be obtained. A KDF allows keys to be created in a manner that is both secure and reproducible by two parties sharing knowledge of the inputs.

The KDF API splits into two parts:

creating a KDF, initialized with specific parameters
deriving keys and data from those parameters as well as from provided key material and other optional inputs

// create a KDF object for the specified algorithm
var hkdf = KDF.getInstance("HKDF-SHA256");

SecretKey initialKeyMaterial = // ...
byte[] salt = // ...
byte[] info = // ...
// create an ExtractExpand parameter specification
var params = HKDFParameterSpec
		.ofExtract()
		.addIKM(initialKeyMaterial)
		.addSalt(salt)
		.thenExpand(info, 32);

// derive a 32-byte AES key
SecretKey key = hkdf.deriveKey("AES", params);

If you have any questions about this, please don't put them in the comments - I'm already way out of my depth here. More details await you in Ana's Newscast in January.

Structured Concurrency

Structured Concurrency is still in the same state as in the JDK 23. The JEP 499 brings no change, to continue getting feedback on the current state of the API. That being said, you can also check the early access version of the Loom project, to get a glimpse at what could come, and also provide feedback on it.

In this early access version, you can create instances of the StructuredTaskScope class using an of() factory method, that can take a Joiner object as a parameter, or a Config object, to configure the virtual threads this StructuredTaskScope can create. You can use the different implementations of the Joiner interface the API gives you, or implement your own. Among other things, the scope object can give the results of the tasks you submitted in a stream. You can produce your final result from that stream, or you can interrupt it if you're happy with what you already have, which is very handy.

Scoped Values

The JEP 487 is about ScopedValues, it is a preview feature, with no change compared with the JDK 23, to get more feedback from the community. Scoped values may be seen as some kind of replacement for ThreadLocal variables, as they solve the same problem: being able to pass values to methods, without using their parameters.

A ScopedValue variable can be bound to a value. This binding exists within the context of a method call. That being said, scoped values can be shared between threads, as long as this thread has a period of execution that is bound to this method call. This is the case for threads created by StructuredTaskScope, but not for threads created using new. Because scoped value can be shared among threads, they should be non-modifiable. But you can still rebind a given scoped value if this what you need.

Vector API

The vector API is still incubating, still waiting for Valhalla, nothing changed, nothing to see, let's move on to language changes.

Primitive Patterns

Since the introduction of type and record patterns, Java gained capabilities for reference types that aren't equally present for primitive types. For example, having a case int i in a switch didn't use to compile and neither did an instanceof int. It also wasn't possible to switch over boolean, float, double, or long values. JDK 24 previews fixes for all of that.

Object obj = // ...

switch (obj) {
	case Point p -> // ...
	// ✅
	case int i -> // ...
	// more cases
}

// ✅
if (obj instanceof int) {
	// ...
}

Boolean b = // ...
// ✅
switch (b) {
	case true -> // ...
	case false -> // ...
	case null -> // ...
}

While those fixes mostly just improve the uniformity of the language, I want to point out one specific addition that will significantly improve code that needs it and that's primitive conversion. Say you have a long l and want to find out whether it fits into an int - you could do that with a range check or, with this preview feature, with an l instanceof int i. Not quite a game changer, but now imagine you want to find out whether that l losslessly fits into a float. Now it's suddenly no longer just a simple range check. But l instanceof float f? Still very simple.

long l = // ...

// does `l` fit into `int`?
if (l instanceof int i) {
	// ... yes
}

// does `l` fit into `float`?
if (l instanceof float f) {
	// ... yes
}

These conversion checks also give meaning to a wider use of primitives in record patterns. If your record has a long component and you write a record pattern, you had to use type long for that component. With this change, you could, for example, use int and the pattern would only match if the number can be losslessly represented as an int.

record Euro(long cents) { }

var amount = // ...
switch (amount) {
	// matches if `amount.cents()`
	// fits into `int`
	case Euro(int ct) -> // ...
	// matches remaining `Euro`s
	case Euro(long ct) -> // ...
}

Primitive patterns are in their second preview and unchanged over their first preview in JDK 23.

Java 23: Restoring the Balance with Primitive Patterns - Inside Java Newscast #66

Flexible Constructor Bodies

This one is straightforward: Constructor bodies can now contain a so-called prologue, code before an explicit call to another constructor with this() or super(). This can be almost arbitrary code - the only exception is that it cannot use the instance under construction, except to initialize fields that do not have their own initializers.

Flexible constructor bodies allow for easier validation, preparation, and sharing of arguments before passing them to another constructor, which comes in particularly handy when chaining record constructors as all but the canonical one are forbidden from assigning fields themselves and must forward to the canonical constructor.

record Name(String first, String last) {

	// compact (canonical) constructor
	Name {
		// check `first` and `last`
	}

	// not all these constructors can exist
	// at the same time but that doesn't
	// matter for the examples

	Name(String last) {
		// validation before `this()`
		if (last.length() == 0)
			throw new // ...
		this("", last);
	}

	Name(String f, String m, String l) {
		// preparation before `this()`
		var fullFirst = f + " " + m;
		this(fullFirst, l);
	}

	Name(String full) {
		// sharing for `this()`
		var names = full.split(" ");
		this(names[0], names[1]);
	}

}

Somewhat surprisingly, this feature also became important for Project Valhalla and its exploration of null-restricted types, but no time to dwell on that here - Brian's recent Valhalla update has more details on that.

Flexible constructor bodies are in their third preview and are unchanged over the last one in JDK 23.

Java 22 Previews Statements Before super(...) and this(...) - Inside Java Newscast #62

Embedded video.

Module Import Declarations

In most circumstances most Java developers prefer the precision and clarity of single-type imports but not only are there some devs who generally prefer star imports... Some men just want to watch the world burn. ... there are also situations where star imports' downsides barely matter and their ease of use reigns supreme - experiments, demos, scripts, early learning are some of them. Module imports are a smarter and more powerful mechanism to mass import types. With an import module $moduleName, developers can import a module's full public API. That's smarter because unlike a star import of a single package, this isn't just a slice of an API and its more powerful because it imports more. And a source file that starts with, say, import module java.sql and import module java.xml couldn't communicate more clearly what the code is dealing with.

Module imports are in their second preview with two small changes:

Modules can now requires transitive java.base, which apparently they couldn't before? (This feels like something I should know but didn't.) This allows java.se to requires transitive java.base, which in turn means that an import module java.se will make the entire Java SE API available, which is super neat.
Star imports are now considered more specific than module imports, which means the former can shadow the latter. So if you import modules that have conflicting simple type names, like java.util.List from java.base and java.awt.List from java.desktop, a star import like import java.util.* can specify which one you intend to import just like you could already do with a single-type import java.util.List. I would not recommend mixing module and star imports like that, but nonetheless the hierarchy "module, star, single-type" (getting more specific) makes sense.

import module java.base;
import module java.desktop;

// one of the following two imports is needed
// to disambiguate `List`; I strongly
// recommend the single-type import!
import java.util.*;
import java.util.List; // <~ do this!

void main() {
	var greet = List.of("Hello", "World");
	println(greet);
}

Speaking of recommendations, I see no reason not to generally prefer module imports over star imports. In fact, I struggle to see any reason to use star imports once this feature is standardized.

Module Imports in Java 23 - Inside Java Newscast #69

Simple Source Files and Instance Main Methods

Here's another feature that targets learners, scripters, explorers, and demo-ers (demonstrators?). If you don't intend to write a larger program, the classic public static void main(String[] args) inside a whole class is a lot of overhead, syntactically but also just by how many concepts are referenced - classes, static, visibility, parameter lists, etc. Why not get rid of that all and allow a simple void main()? You can even omit the surrounding class and for such simple source files you get an import module java.base for free, so you can dive right in with collections, I/O, math, dates and times, and more.

// OPTION #1 - THE WHOLE SHEBANG
import java.util.List;

class Hello {

	public static void main(String[] args) {
		var greet = List.of("Hello", "World", "!");
		System.out.println(greet);
	}

}

// OPTION #2 - SIMPLIFIED MAIN METHOD
import java.util.List;

class Hello {

	void main() {
		var greet = List.of("Hello", "World", "!");
		System.out.println(greet);
	}

}

// OPTION #3 - SIMPLE SOURCE FILE (WITHOUT CLASS)
void main() {
	var greet = List.of("Hello", "World", "!");
	println(greet);
}

Simple source files and instance main methods are in their fourth preview and unchanged over the last one in JDK 23.

Script Java Easily in 21 and Beyond - Inside Java Newscast #49

Performance

JDK 24 also ships with a bunch of performance-related improvements:

Project Leyden ships its first feature, namely ahead-of-time class loading and linking
virtual threads now synchronize without pinning
the garbage collectors Shenandoah and ZGC further embrace the generational hypothesis and G1 got a late barrier expansion
we get experimental compact object headers
full JDK runtime images can be a bit smaller

But more details on all of in the next Inside Java Newscast, next week. I'll see you then, so long...

Watch the video.

Java 24 Stops Pinning Virtual Threads (Almost) - Inside Java Newscast #80

Nicolai Parlog — Thu, 21 Nov 2024 00:00:00 GMT

On Java 24, virtual threads will no longer be pinned inside synchronized blocks, which increases ease of adoption

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna look at JDK Enhancement Proposal 491, which is already integrated and available in the latest JDK 24 early access build, links to both in the description. With this change, virtual threads are no longer pinned within synchronized blocks, which removes their biggest source of scalability issues. We'll also look into the remaining cases of pinning and how to observe it before we briefly touch on thread capture and io_uring. But first a quick virtual thread recap - jump to this timestamp to skip it. Ready? Then let's dive right in!

Virtual Thread Recap

As you probably know, a virtual thread is about as real as virtual memory and just like it, it needs an underlying mechanism that does what the virtual thread claims to do, namely execute instructions. At the very bottom of the abstraction cake, that mechanism is a CPU core. One layer up sits the operating system that schedules OS threads on top of cores. Another layer up sits the Java runtime that maps OS threads one to one to its own threads, which we now call platform threads. Before Project Loom, all threads within the Java runtime were platform threads.

The icing on this abstraction cake are virtual threads. The JVM maintains a dedicated pool of platform threads, called the carrier thread pool, and schedules virtual threads onto these carrier threads. It does so by mounting a virtual thread onto a carrier when work needs to be done and unmounting it when the virtual thread blocks. When unmounting, the virtual thread's data (like variables and stack frames) are copied to the heap and then, when the thread gets remounted, the data is copied to that new carrier thread, which is likely to be different from before.

In theory, as long as there are virtual threads that want to work, carrier threads are busy executing instructions, but there are two mechanism that can undermine this optimal scenario: pinning and capturing.

In either case, a blocked virtual thread may still be mounted onto a carrier thread, which must hence also block - that's not good because compared to virtual threads, carrier threads are a very expensive and rare resource. But while the result is the same, pinning and capturing happen for different reasons and turn out different. Let's start with pinning.

Synchronized Pinning

There are situations where unmounting a virtual thread from a carrier thread would cause issues. Take synchronization:

When code enters a synchronized method or block, it tries to acquire the monitor that is associated with the instance that is being synchronized on. If the monitor is available, the thread acquires it and enters the block - otherwise it needs to wait until the monitor is released, which happens when the thread that currently holds it exits the synchronized block. To implement that mechanism, the JVM stores for each monitor the ID of the thread that currently holds it, but, unfortunately, it doesn't know about virtual threads and so it stores the carrier thread ID.

Now imagine, there was no pinning. A virtual thread enters a synchronized block, which means the JVM stores the ID of its carrier thread as holding that monitor. Some blocking operation unmounts the virtual thread and sends the carrier thread back to the pool, where it picks up another virtual thread, which just so happens to run into the same synchronized block. Should it enter? No, the first virtual thread is still in that block, after all. But can it enter? Yes, because it happens to run on the carrier thread with the right ID. Good luck debugging that!

The intermittent fix was to pin the virtual thread to the carrier thread when it acquires a monitor. If there is no blocking operation while the monitor is held, pinning is free, but if there is, it guarantees correctness by ensuring that the carrier thread stays put and can't stroll off to violate the monitor semantics. And for similar reasons, a virtual thread gets pinned when waiting to acquire a monitor and when calling Object::wait.

This is all good and works just fine... until it doesn't. If your app happens to have a lot of synchronized methods with a lot of blocking operations within them, pinning can cause scalability issues and, in the worst case, even dead locks.

So the folks behind Project Loom, most notably Alan Bateman and Patricio Chilano Mateo, set out to fix this. In JDK 24, the monitor mechanism knows about virtual threads and uses their ID to keep track of who holds which monitor. Consequently, neither synchronized nor Object::wait requires pinning anymore. That's great! It removes the biggest hurdle for straightforward adoption and scaling with virtual threads. If that's not worth a like, I don't know what is.

Native Pinning

Unfortunately, JDK 24 doesn't remove all pinning, though. If you call native code, say a C library, that code may contain pointers to native variables on the stack that it can read and write at any time. Stack variables belong to the thread, though, and so it is important that native code sticks with the same thread. Otherwise this can happen:

a virtual thread calls into native code
the native code calls back into Java
the Java code blocks the virtual thread
and then the runtime unmounts the virtual thread and copies its stack to the heap

That last step severs the connection between the native code and its variables on the stack. And unless the virtual thread is coincidentally remounted onto the same carrier thread, the pointers all point to the wrong thread's stack, which would lead to garbage reads and destructive writes. That's catastrophic.

This issue could potentially be solved with some complex virtual memory mapping tricks, but there's a much simpler solution that still guarantees correctness: When there's a native frame on the stack, pin the virtual thread to its carrier. That way, any call from Java into native code is guaranteed to be executed by the same thread until it completes, regardless of intermittent callbacks into blocking Java code. Of course that comes with the same scalability challenges as pinning during synchronization, but it's much rarer. For this to become a noticeable drag, you need a lot of calls into native code that calls back into Java code that then ends up blocking - not particularly common.

That said, class loading goes through native code, so when virtual threads load classes, they're pinned. That is probably most relevant in class initializers because if they contain blocking operations, which should be exceedingly rare, though, the virtual thread is not unmounted. For more details, see the Future Work section of JEP 491.

If you want to check whether the remaining pinning is of any concern to you, use JDK Flight Recorder to observe the event jdk.VirtualThreadPinned. It is now emitted every time a virtual thread is pinned and includes the reason for pinning as well as the identity of the carrier thread.

Capture During File I/O

Let's briefly talk about the other potential scalability issue for virtual threads and that's capture. While waiting for locks, network sockets, now synchronization frees the carrier thread, many file system operations capture it, meaning it will be blocked while file I/O is happening. That's mostly down to OS and filesystem limitations but there was hope that this problem could be solved at least on Linux by relying on io_uring but that's not looking good:

Reimplementing file I/O on top of io_uring promises to be quite disruptive.
io_uring has varying support across kernels, distributions, and container environments.
It requires quite a bit of bookkeeping that is significant compared to read times from local SSDs.

So it's a lot of work for an improvement that is neither substantial across the board nor universally available and so it's been put on hold. Never say never, I guess, but it's surely not gonna happen soon.

Talking about soon, in two weeks, JDK 24 will enter ramp-down phase 1, which means its feature set will be frozen. I'll see you then so we can go over everything that made it - and it's a lot! So long...

Watch the video.

Release Your (Java) Projects Like OpenJDK With Tip & Tail - Inside Java Newscast #79

Nicolai Parlog — Thu, 31 Oct 2024 00:00:00 GMT

"Tip & tail is a release model for software libraries that gives application developers a better experience while helping library developers innovate faster"

Every experienced developer knows, when it comes to managing dependencies, here be dragons. Minor updates can come with major changes, unbreakable diamonds get you stuck, and seemingly small updates ripple through the entire dependency tree. Being a dependency makes everything worse: Now you're also worrying about release trains, feature backports, and security patches.

Much of this complexity is inherent in a rich and diverse ecosystem like Java's but that doesn't mean there isn't still room for improvement. In 2018, OpenJDK itself set out to tame its dragon and a few weeks ago, it shared its success story. Now it's time for us to do the same.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're going to discuss the "Tip & Tail" model, OpenJDK's solution to its own development and release challenges and its proposal for how the wider ecosystem may overcome theirs, too. This is laid out in JDK Enhancement Proposal 14, which should be seen as a conversation starter on this topic. Ready? Then lets dive right in!

Defining Tip & Tail

So what is "tip & tail" and how does it work? The JEP does a great job at explaining that in its first few lines:

Tip & tail is a release model for software libraries that gives application developers a better experience while helping library developers innovate faster. The tip release of a library contains new features and bug fixes, while tail releases contain only critical bug fixes. As little as possible is backported from the tip to the tails.

So in practice that means that a project following T&T has a main development branch, called the tip, from which new versions are released as they would be today: major, minor, patch versions (if you use semantic versioning) - doesn't matter. But every now and then, at the maintainers' discretion, a new release branch is cut from the main branch and that's called a tail. So those terms aside, so far, so common for every project that supports several release trains. What's essential to T&T is what additions to the tip get backported to the tails: barely anything.

no features
no performance improvements
only critical bug fixes
but all security fixes

This means, there will only ever be patch releases from a tail. I'll get to why that's so crucial in a minute but there's another important difference between tips and tails that you need to know about, too, and that's their dependencies: A project's tip can pick and choose whether to require its dependencies' tip or tail releases - more about that choice later. But a tail should only depend on the tail releases of each dependency.

So a tip has a development style, releases, and dependencies that are common for most projects today whereas the tails only see backports of security and critical bug fixes, only release what semantic versioning would call patch versions, and only depend on other tails. And that's how you tame the dragon!

Benefits for Users & Maintainers

Ok, that was tip & tail in a nutshell, now let's discuss why - why propose this, what are the intended benefits? And let's start at the tail. The minimal amount of backports plus the limitation of only depending on other tails means that users of a tail release are guaranteed continued and hassle-free security and critical bug fixes.

Imagine an application that either sets out with a conservative dependency management approach or adopts it when main feature development is done and it enters maintenance mode. By picking tails of all of its dependencies, it can no longer run into issues where, for example, a fix for a critical bug or a vulnerability is only available in a new major version and now it has to make the difficult decision of either running an unreliable or unsafe dependency or accepting the churn that comes from updating. Or the situation where a patch update pulls in a minor update of its dependency, which pulls in a major update of its dependency, causing a butterfly effect that leads to an entirely different dependency tree and all the instability that comes with that. So that's good for users interested in stability.

At the same time, the minimal amount of backports makes tail releases very cheap to maintain, to the point where even smaller projects can support multiple release trains. That means they don't have to make their main development line, the tip, work across JDKs 8 to 23, for example. Doing that is a continued drag on many projects as it keeps them from using JDK features that would make them more productive and from offering their users the best possible integration with new features. Instead, a project can have a tip on, say, JDK 21 with tails for JDKs 8, 11, and 17. That sounds like a lot more work, but remember that those tails cause minimal effort and the tip can use and support new JDK features directly, which makes development more efficient.

In this scenario, library maintainers can drive the tip ever-forward and deliver the best possible version of their idea without being held back by an outdated JDK. Whether it's virtual threads, pattern matching, the FFM API, value classes once they come out - maintainers can adopt these features as soon as they're released, all the while ensuring that tails are safe and sound on older JDKs.

Users, on the other hand, can decide what they value most. If it's stability, they can can get more of that by depending on tail releases. If it's innovation they want, they can get more of that by depending on tip releases. And if they want both, they can't have it (for the same dependency), and a decent chunk of the dependency management complexity comes from the illusion to the contrary, comes from users expecting and developers trying to maintain release trains that are stable and innovative, that work on JDK 8 but also support new language features and APIs and deal with ongoing deprecations and removals. Tip & Tail accepts that stability and innovation are at odds and offers a method that allows users to decide what they prefer and maintainers to provide release trains for each demographic. This, as JEP 14 puts it, "helps the Java ecosystem maintain the balance between innovating rapidly for new development and ensuring stability for long-term deployments".

Managing Tip & Tail Dependencies

There's a lot more to talk about on this topic and I will get to a few aspects in a second but before that I want to implore you, particularly if you're maintaining an open source library, to read JEP 14 and consider adopting tip and tail for your projects. I truly believe that this approach may solve some of the issues we've seen in the Java ecosystem over the last few years and make it more coherent, more well-structured, more innovative, and more stable.

One aspect is probably very obvious, but let me state it anyway: Since version 9, the JDK has followed this model. It creates a new tip release every six months and every few releases (so far 11, 17, and 21) become tails with long-term support from multiple vendors, which is reflected in continuous security and critical bug fixes, usually as backports from the main branch.

So when I said tails should depend on tails, that included the JDK and a project's tail release should be baselined against a JDK version with LTS. And it really is enough to work on one of those - tails don't need to work on a matrix of JDK versions, particularly not if a project indeed creates a tail per JDK with LTS. If users upgrade form JDK 11 to 21, for example, they can be expected to upgrade other dependencies as well.

Speaking of dependencies, earlier I mentioned that a tip's dependencies can be either tips or tails. Each project will have to figure out the details on their own, but here are a two observations to help with that:

The more tips your tip depends on, the more time it will take for them to release a respective tail when you want to create your own tail.
A tip is encouraged to update a dependency, including on the JDK, from an old tail to a newer one or from a tail even to a tip as soon as it can benefit from that, for example when:
- the newer version offers a feature it wants to use or integrate with
- the newer version contains a change, like the removal of a deprecated API, that makes it non-trivial to support the old and new version side by side

Remember, don't jump through hoops to support multiple versions. Pick the newer one and consider a new tail for the older one you leave behind.

Nomenclature & Lightning Round

One last thing before a quick lightning round: While Tip & Tail can remove a chunk of the complexity of managing dependencies, there's still a lot of it left, not least because much of it is inherent in such a rich and diverse ecosystem. The diamond problem, for example, will remain alive and well, a dragon for another day.

But what Tip & Tail also offers is structure and nomenclature - a shared vocabulary to express intent and expectations and to discuss challenges. While investigating this topic, I came up with a number of "failure cases", where a T&T dependency tree would go up in flames, but I eventually realized that these cases exist regardless of T&T - it's just harder to clearly describe them and attribute a cause. So even when it can't fix issues, Tip & Tail can help us understand them.

Ok, lightning round:

What I said about depending on the JDK tip vs tail, for example when to move on and not to jump through hoops to support multiple versions, also applies to a project's other dependencies.
Tip & tail does not specify when or why tail trains are created, nor when or why they are discontinued.
Tip & tail does not constrain a library's release cycle.
Tip & tail does not dictate a version numbering scheme - for example, it says nothing about semantic versioning even though I've used that as an example a lot in this video. It says nothing about the use of alpha/beta/release-candidate labels or any other metadata about the library.
I'll see you again in two weeks.
So long...

Watch the video.

Advanced "Java 101"

Nicolai Parlog — Tue, 15 Oct 2024 00:00:00 GMT

Java's success as one of the most used programming languages in the world comes in no small parts from its approachability but what may have been an easy entry into programming in the mid 90s, appears laborious today and so, in recent years, Oracle and OpenJDK have worked to improve the situation.

Java's success as one of the most used programming languages in the world comes in no small parts from its approachability. But what may have been an easy entry into programming in the mid 90s, appears laborious today: classes, (static) methods, visibility, parameter definitions, arrays, JDKs, the compiler and launcher, IDEs - all that are concepts and tools that newcomers either need to learn or ignore.

In recent years, Oracle and OpenJDK, particularly Project Amber, have set their sights on these issues and worked on a series of improvements:

direct execution of source code
considerable simplification of the main class
simplified interaction with the terminal
enabling a programming paradigm that is better suited to small projects
a playground that allows quick and easy experimentation
a VS Code extension that meets developers where they are

But it's not enough to improve the technological underpinnings. These developments also enable updates to curricula that make Java more approachable and more immediately usable.

Big News from Project Valhalla - Inside Java Newscast #77

Nicolai Parlog — Thu, 03 Oct 2024 00:00:00 GMT

At JVMLS 2024, project lead Brian Goetz presented the current state of Project Valhalla - this video summarizes the proposed changes to the programming model.

Ho! Ly! Sh*t! Have you watched Brian's JVMLS talk about Project Valhalla? It blew my mind! How Valhalla reached "the peak of complexity" and is now seeing "the virtuous collapse"? How surgical the changes to the programming model might be? So cool!

I know many of you have watched it, but I also know that not many of you watched it to the end. So today we're gonna distill the proposed programming model - just the part that we would interact with daily - into a short and sweet 10 minutes. A recap for the attentive, a hell of a ride for everybody else.

Embedded video.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about the current state of the draft proposal for value types in Java. And when I say "draft" and "proposal", I mean it. This is not a done deal, this is not how it's definitely gonna be, and it surely isn't something that's gonna happen in the next months or so. So we're not here to discuss how you'll program Java in 2025 - we're here to look behind the scenes of an ongoing project. Deal? Then let's dive right in!

Polar Opposites

Java's reference types and primitives are different, very different, and value classes are something of an in-between that would allow us to create primitive-like types with most of the comfort and expressiveness of regular classes. Hence the slogan "codes like a class, works like an int". So before we go into the current state of the draft proposal, let's list those differences and then we can work through the list to see where value classes land. For reasons that will become clear in the next section, I'll refer to the regular classes we all know as identity classes.

Codes like a class, works like an int

So most obviously, identity classes can be user-defined but primitives can't. Identity classes have members, methods, supertypes, etc. and primitives don't. Identity classes have a flexible construction protocol whereas primitives have reasonable defaults and are usable without initialization. Identity classes have an object header and are referenced by pointers whereas primitives are dense (meaning no headers) and flat (meaning no pointers). References are always written atomically but primitives larger than 32 bits technically don't have to, even though they all are on modern hardware. Identity classes are nullable, can be used as parametric types in generics and - as the name suggests - have identity, whereas none of that applies to primitives.

Ok, time to get going, and since I apparently like saying "identity" a lot, let's start there.

Identity

Instances of classes as we know them all have identity, some inherent quality that identifies each instance even as it may change its value over time. Two lists may contain the same objects but that doesn't make them the same list. Two capital-I Integers may both be 5 but can still be distinct instances.

var listA = List.of("a", "b", "c");
var listB = List.of("a", "b", "c");
// false
var sameLists = listA == listB;

var fiveA = new Integer(5);
var fiveB = new Integer(5);
// false
var sameFives = fiveA == fiveB;

And those distinctions are important when one of the instances is mutated, locked on, or a series of other so-called identity-sensitive operations is executed on it. While maybe not under that name, most programmers are deeply familiar with that concept as it underpins the == comparison, because that checks for identity.

At the same time, we know that this concept doesn't apply to primitives. Can there be two different ints with value 5? No - even the question barely makes sense.

And as per the draft proposal, the classes that answer that question with "no" can be marked as value classes with the modifier value. So value class Point or even value record Point. First and foremost, this is a semantic statement that types like that don't need identity, which means:

they're immutable in the sense that their fields are all final
identity-sensitive operations cause errors at compile or run time
if they're a concrete class, they're implicitly final
if they're an abstract class, yes abstract value classes (think of Number, for example), they must not depend on identity

And that's pretty much it. As proposed, value classes can have arbitrary fields, multiple constructors, methods; they can implement interfaces and even extend abstract value classes. "Codes like a class." Note that they're also reference types. We'll come to the memory layout later, but you should not think of value as a synonym for "flat". Say it with me: It's a semantic statement. And one that will be applicable to tons of classes that don't need identity, including a lot in the JDK - we'll probably see the eight primitive wrappers, Optional, and many types in the date/time API become value classes.

There are more details on all this in JEP 401 and you can even try out value classes today with the most recent Valhalla early-access build, but since things can still change, I'd rather wait with a deep dive until the JEP is targeted to a release. Instead, let's move on to nullability.

Nullability

When I first read this on a mailing list a year or so ago, it blew my mind: The current state of the draft proposal coming out of Project Valhalla includes nullness markers! You know those question marks and exclamation marks (also called "bangs") you put behind a type name? I didn't think that was possible, in fact I'm on record saying just that more than once. But I'll never be as happy for being proven wrong as I will be over this.

So, under the current proposal, a variable of type String? can contain a string or null, whereas String! cannot be null! A blanket String variable would be of unknown nullness - think of it like a raw type but for nullness. Again, I don't want to go into details here - there are two JEP drafts, one for null-restriction of identity classes and another for null-restriction of value classes, that do just that, although they're not entirely up to date with recent developments. Instead I want to focus on what may not seem overly consequential but turns out to be very important for us here and that are default values and initialization.

First, let's observe that since the primitive wrapper classes are already identity-less value classes as per the previous section, it's mostly just nullness that sets them apart from their primitive counterparts. For example, Integer can be null but int can't. And so an Integer!, which cannot be null, is really very much an int - even though not quite, but we can ignore the remaining differences today. For now, think of primitives as the legacy version of Integer!, Float!, etc.

One thing these specific null-restricted types all have is a good default value that fields and variables can be initialized to. Integer! has zero, Boolean! has false, etc. But what would a variable or field of type String! be initialized to? null sounds wrong, given that the type explicitly forbids this.

Variables are fairly straight-forward as definite assignment analysis can ensure we write a value before reading the variable.

// VARIABLES:
String! greeting;
// doesn't compile (even today)
// with error:
//   variable greeting might not
//   have been initialized
println(greeting);

For fields, the unexpected save comes from Amber's exploration of more flexible constructor bodies, which preview since JDK 22. I made a whole video about that but the summary is that under that proposal you can have statements in the constructor before the eventual call to another constructor with this() or super() as long as those statements don't touch this - ...

I told you, homeboy

You can't touch this

Well, actually you can but just to assign fields - no instance method calls, for example, in this so-called preinitialization context. It seems like this relaxation of the construction protocol will be immediately exploited by Valhalla, which requires us to assign all null-restricted fields in that pre-construction context.

// FIELDS:
value class Greeting {

	private String! text;

	Greeting() {
		// doesn't compile because
		// `greeting` wasn't
		// assigned
		println(greeting);
	}

}

That means null-restricted fields will actually be null for a few statements, but no code will ever be able to observe that.

That, the definite assignment analysis for variables and a kind of array constructor that I'll also skip here, means that we can declare non-null variables, parameters, and fields of all types and array types without a type having to be prepared for it. That means a soon-to-be value class like LocalDateTime, for which no good default value exists, can still be used for null-restricted fields. And this is essential for the next difference between identity classes and primitives.

Memory Layout

Ok, so let's talk about the memory layout. Primitives like int and double are simple bit patterns flatly embedded in fields, the stack, or registers. Identity classes, on the other hand, are reference types, meaning each instance sits in a unique memory location on the heap and has a bunch of header bits for identity-sensitive operations. Parameters, variables, and fields reference it by pointer. Or at least that's the illusion the runtime maintains. If analysis shows that an object doesn't escape a certain scope, the runtime can do really nasty things to reduce the negative performance impact of headers, indirections, and heap allocations.

And the same applies to value classes. Technically, they're reference types and that's how we should think of them, but because the runtime doesn't have to track their non-existent identity it can be even nastier to to them. It can, for example, at any time decide not to represent a value object as a reference type on the heap and instead shred it into its fields and keep them on the stack. It can also embed a value object directly in a field or array, thus removing the indirection of a pointer.

And the memory layout is also where nullability comes back in. If a value class wraps a numeric primitive, say a long, then all 2^64 bit patterns are already used and if a variable of that type could be null, a 65th bit is required, which will balloon to 128 bits in total on modern hardware.

value class Euros {

	// total amount
	private long cents;

	// ...

}

// requires vsc64 bits for long
// plus 1 bit for null ~> 65 bits
Euros eur65 = new Euros(420);

// no null ~> requires 64 bits
Euros! eur64 = new Euros(420);

So by marking a field or array type as non-nullable, we give the runtime the information it needs to remove that extra bit that became 64 bits.

Taken together the runtime can give us primitive-like performance for non-nullable value objects and even a pretty decent speedup for nullable ones. I want you to pause for a moment and let that sink in. We would get "custom primitives" with great performance as a consequence of good, domain-driven decisions for our types' identity requirements and our variables' nullability. And all we'd need to learn for that is how to wield the new keyword value, how to use ? and !, and how to order constructor statements - that's crazy! I would want those things even without any performance gains and we get those on top? I'm at a loss for words.

Remaining Differences

Ok, let's go back to our list of differences and see where the proposed value classes fit in. As discussed, they're identity-less like primitives but can still be null, although thanks to null-restricted types they won't always have to be. Their memory layout is technically that of identity classes, but the runtime has a lot of leeway to optimize all the way down to the density and flatness of primitives. We didn't get to atomicity and even Brian's talk is very scarce on details here, but suffice it to say that value classes will probably have atomic loads/stores by default but can opt out of that if they want the performance gain. All that's the "works like an int" part.

As for "codes like a class", just like identity classes, value classes can be user-defined, have members, methods, supertypes, and a flexible construction protocol. And since they're technically reference types, they'll work just fine with generics and so will their null-restricted variants. So, for a custom value class ComplexNumber we can have a List<ComplexNumber!> and then likewise, we can also have List<Integer!>, which is basically List<int>. As per the current draft proposal, this is how we'd get "generics over primitives", namely as "generics over null-restricted primitive wrappers". There are plans for how the runtime can then flatten them, so that the backing array of an ArrayList<ComplexNumber!> or ArrayList<Integer!> can contain primitive values instead of pointers, but that'll probably come after the language changes.

And I can't wait for all that to happen. When? Don't check the comments, I'll definitely not leave my guesses there.

Billy will be here in two weeks. I'll see you in four. So long ...

Watch the video.

How to Read a JDK Enhancement Proposal - Inside Java Newscast #74

Nicolai Parlog — Thu, 01 Aug 2024 00:00:00 GMT

OpenJDK evolves Java through JDK Enhancement Proposals, JEP for short, and uses them to communicate its intentions, but the the devil is in the details

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna dive back into the string template drama - sort of. Back in June, when JDK 23 was forked, a lof of people looking into that and even a few reporting on it didn't quite catch that string templates were no part of 23. Why? Because they didn't read the JEP correctly and since that happens again and again, I thought I'd take this opportunity to talk about how to read a JEP. First some theory and then I'll answer a bunch of frequently asked questions on this topic. Ready? Then let's dive right in!

JEPs From 10'000 Feet

Let's start with a triviality that only a fool wouldn't know. JEP of course stands for Java Enhancement Proposal, Java Enhancement Proposal, Java Enhancement Propo, Java Enhanc Crap, there goes my carefully crafted illusion of expertise. But we can learn something from that: How easy it is to overestimate one's understanding of these documents.

Just three simple examples:

they're a description of a JDK feature
all features get JEPs
JEPs are immutable

And those are all wrong. Not just on a "well, actually"-level, no, they're very wrong. So before we get into JEP details, lets set the stage.

"An enhancement is an effort to design and implement a nontrivial change to the JDK code base or to do some other kind of work whose goals, progress, and result are worth communicating broadly." A JDK Enhancement Proposal, then, is at the center of that communication. In its early state (more on states in a minute) it forces its authors to put their analysis, research, and ideas into writing for the wider Java but specifically the OpenJDK community, which needs to decide whether to move forward or not. And as the JEP progresses through the states and the idea evolves due to discussions, prototypes, and feedback, the JEP is updated accordingly and eventually serves as the focal point for the decision whether to adopt the proposal. Whether adopted or not, after that, it stands (usually unchanged) as documentation of what was done and why.

Already we can see a few core properties of JEPs that get easily overlooked:

OpenJDK uses JEPs as part of its development process, which implies certain requirements and limitations
during its active lifetime, the text is a proposal of what should be (in the eyes of its owners) not a description of what is
a JEP is a living document that goes through considerable rewrites and multiple state changes

Before we get to those states and a few more JEP details, let's get a few frequently asked questions out of the way.

JEP FAQ #1

So, where can I learn more about JEPs?

Plenty of places actually:

the URL for JEP 0 leads to an overview page with all JEPs that was recently restructured for better readability
JEP 1 describes the overall process but is mostly superseded by a JEP 2.0 proposal
JEPs 11 and 12 describe how incubator modules and preview features are being developed

And there are of course links to all this in the description.

What do JEP numbers mean?

JEPs proposing JDK features or infrastructure improvements like the migration to Git get an incrementing number that was started at 101 - at the moment, the next free number is 483 and we're currently seeing about a dozen JEPs in each JDK release. JEPs that change the OpenJDK development process, so-called process JEPs, get the numbers under 100, with 1 to 3 and 11 and 12 already taken. What's with the split of smaller vs larger than 10? Haters will say I wrote this script last minute and couldn't find out in time but let's not go there. As soon as I know, I'll pin a comment.

Are JEPs self-contained?

They strive to be but there are limits to that. Particularly when they connect to other features that are also in planning, this connection is usually not explored due to the nature of a JEP - proposing one enhancement at a time. For the larger vision behind them, it's often better to search for documents of the OpenJDK project proposing them, mailing list exchanges, or videos on this channel. Subscribe and ding that bell.

Do JEPs capture all changes in a new release?

No. Like, noooooo. The bar that a change needs to clear to become a JEP is quite hight and many, many, many changes don't even come close. Please read the release notes for every new JDK release to get the full picture. Or have Billy read them to you! He does that for every JDK release in the week it comes out - here's the one for JDK 22.

What's the connection to the Java Community Process and the Java Specification Requests?

A proper answer to that would take a bit of time, so I'll try a short and oversimplified one: The JCP and JSRs are mainly concerned with the Java Platform Specification as a whole. The OpenJDK Community, and hence JEPs, are mainly concerned with the design, specification, and implementation of specific features. When a JEP wants to change part of the specification, those changes are rolled up into the Platform JSR for the relevant release.

JEP Progression

A minute ago, I mentioned that JEPs go through states. And indeed they do, as you can see in this handy diagram. No need to rush to the screen if you're currently cooking, commuting, or whatever else you're doing while having me on, yapping in the background. Imagine a diagram with 11 nodes, 24 arrows, and 13 annotations. Yeah, it's a bit of a mess, so let's talk through it.

The first state in every JEP's life cycle is Draft - a lot can change here and it's not advisable to form an opinion about what's going to happen this early on. Once the JEP owners are happy, they submit the JEP and then the OpenJDK Lead, Mark Reinhold, may make it a candidate JEP. And this is the state most JEPs have for most of their existence. As work on them progresses, further changes will be made until eventually, they go down the road of publication: Owners propose to target a specific JDK release and the project lead can confirm, making the JEP targeted. Once the code is merged, the JEP is integrated, and once all follow-up work is completed, it's complete. Still, however unlikely, things can change. They're only settled once the JDK version is released, at which point the JEP is closed as delivered. Early on, owners can also withdraw a JEP or the OpenJDK lead can reject it and once it has been targeted, the owner or the project lead can propose to drop to it.

The importance of these states is hard to overstate. This was one source of the string template confusion: Yes, the text of JEP 465 said, in fact still says, "We propose to finalize the feature". Similarly, the text of JEP 468 says that derived record creation will be a preview feature in JDK 23. But that's just what's being proposed - were those JEPs targeted to JDK 23? No? Then the texts don't matter. Period.

So when reading a JEP, carefully parse the header. There you'll find the JEP's authors and owner, its status, what mailing list to contact, last update date, and a link to the JBS issue. Oh right! I should probably mention that a JEP is just a special kind of issue in the JDK Bug System, JBS for short, the JIRA instance OpenJDK uses as issue tracker. You don't need an account to view them and it comes in handy when you want to check a JEP's history, for example.

The other mistake people made with string templates is that they mistook "no JEP" for "no news" but preview features need to be renewed on every release, even if unchanged. So "no JEP" doesn't mean mean "no news", it means "no feature". I'd love to get deeper to into the process and technical aspects of preview features, but I'd rather answer a few more JEP-related questions. Let me know in the comments if a Newscast on that topic is something you're interested in.

JEP FAQ #2

There's a JEP with my favorite feature - when will it be released?

That's the wrong question to ask. The more interesting one is whether it will be released. (What?) Anything up to and including candidate JEPs may neither have nor, in the worst case, ever get an implementation. Later states require one but it can still get rejected. A JEP only describes a real feature once it reached closed/delivered - anything before that is speculation, albeit with varying degrees of uncertainty. And as a corollary to all that: Nobody can say when it gets released.

A JEP lists my favorite feature as a non-goal - why do you hate it?

Non-goals must be understood in the context of a JEP. They really just define its scope and clarify what this specific JEP is not trying to do. Generally speaking, that doesn't mean anything about OpenJDKs overall attitude towards that goal. In fact, somebody could be drafting a JEP right now that makes that very non-goal its goal and starts working on it.

Can there only be one JEP for any one feature?

No. While that rarely happens, it is entirely possible for multiple JEPs to propose features that solve partially or even fully overlapping problems.

How can I create a JEP?

You need to be a contributor to OpenJDK, which requires you to participate in mailing list discussions, have made a few small contributions, and have signed the Oracle Contributor Agreement. But more important than that organizational hurdle is that you have identified something really worth working on, which is best figured out in communication with the respective OpenJDK group or project. The best way is to start is with a mail laying out the problem and maybe your research into possible solutions - don't focus on a proposed solution before you convinced anybody that there's a problem worth solving.

How can I contribute to a JEP?

Give feedback! That's the easiest one: Give feedback. You don't need JBS access for that, by the way, just write to the mailing list that's listed in the JEP's header. Ideally, with practical feedback after trying out a prototype or preview feature in practice. That feedback can of course be critical and propose changes but please also mention what works and why - this is almost as important as what doesn't work. Once you've done that for a while, avenues for other contributions will open up by themselves.

Nice, thank you!

Ok, I hope that answered all your questions but if it didn't, please ask ahead in the comments - as always I'll hang out there to reply.

And that's it for today on the Inside Java Newscast. If you liked the video and think more Java devs should see it, help us spread the word with a like. Subscribe if you didn't already and I'll see you again in... oh right, that's gonna be a while actually. A couple of months I asked Ana and Billy to take over an episode or two and by coincidence they picked the remaining ones from now up to and including the JDK 23 release, so I'll see you again on the live stream for the JDK 23 release. So long ...

Watch the video.

Integrity by Default - Inside Java Newscast #73

Nicolai Parlog — Thu, 18 Jul 2024 00:00:00 GMT

Integrity is a cornerstone of the Java Platform as it enables/bolsters reliability, maintainability, security, and performance, but there are operations that undermine it. Now, Java wants to lock them down by default.

Correctness, security, performance, maintainability - to varying degrees these all depend on one fundamental property of the Java Platform: integrity. But, maybe because it is so fundamental, it doesn't get discussed very often, at least not directly. But whenever we talk about encapsulation of internals, about command-line flags for agents, about Unsafe, or about the limits of certain performance optimizations, we're effectively talking about integrity. So let's take a closer look at it as well as at Java's ongoing push in that direction.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about integrity by default. Specifically, how that concept has been a goal that Java's been working towards for over a decade now, and on various avenues, but often implicitly. Only now does the draft for a JDK Enhancement Proposal tie these efforts together and explain the importance of integrity by default. Ready? Then let's dive right in!

What Even Is Integrity?

So what even is integrity? (Default or not.) In our context, it essentially means that something does what it says on the tin. More formally, according to the JEP...

We say that a computing construct has integrity if, and only if, its specification is complete and its implementation is correct with respect to the specification.

Those constructs can be anything, from everyday language features like array access and for loops to the classes and modules that are built on them - be they in the JDK, in our dependencies, or in our very own code bases. The essential observation is that integrity (the completeness of specification and the correctness of implementation) composes well. If a set of constructs has integrity, then the larger construct that is built from them has integrity, too.

Take Java arrays as an example. Java's specification has quite a few things to say about arrays:

their length is defined during construction
their length never changes
the first element has index 0
only access within the bounds from 0 to length-1 will succeed
and reading at an index will return the element that was last written to it (ignoring concurrency)

When put together, the specifications of all these features completely specify arrays as a feature. And because all their implementations are correct, so is the implementation of arrays as a feature. So the integrity of these features allows us to say that arrays in Java have integrity.

This mechanism applies just the same to other constructs in the Java Platform as well as the programs we build on it: Type safety, well-defined initial states, the Java memory model, all its APIs, our domain logic etc. - they're either directly specified or, more often, rely on the specifications of the constructs that are used to implement them. Likewise, their correctness hinges on correctness of their constituting constructs.

So, to rely on our programs' integrity we need to rely on the integrity of essential properties of the Java platform, which in turn often emerge from the integrity of its constructs. And while Java generally provides that integrity, there are a few features that can nullify all guarantees. And integrity by default means that these features are off by default, that unless the person running a Java program makes a conscious choice to trade away integrity, it will be guaranteed.

So let's look at a few ways to undermine integrity and what Java has done and is doing in each of those areas.

Deep Reflection

Encapsulation is a key ingredient when reasoning about integrity. Say we're writing a class and one invariant is that a mutable int field has to be non-negative. How do we judge whether the implementation upholds that invariant, which would imply its correctness and thus the class' integrity?

If the field is private, we only need to reason about code in the same source file and can then lean on private's integrity to guarantee that no other code can change that field. If, on the other hand, Java didn't offer visibility modifiers or we couldn't rely on their integrity, we'd have to analyze all of our source code plus that of all dependencies to ensure correctness.

public class Counter {

	// always non-negative
	private int count;

	// … code operating
	//   on `count`

}

Did you catch that?

or we couldn't rely on their integrity

For the almost 20 years from 1998 to 2017, we actually couldn't rely on the integrity of visibility modifiers. By using the reflection API's setAccessible-method, all code on the class path could change any private field it wanted, thus voiding the integrity of visibility modifiers. Oh and for good measure, that of final, too.

What were the consequence? A bunch actually, most directly an increased maintenance effort when changes in internals of OpenJDK or 3rd-party libraries cause issues in the wider ecosystem - there's a link to one example of many in the description, where refactoring a JDK-internal class caused an issue in a community project. Then there are some performance improvements that couldn't be made, for example because the just-in-time compiler can't treat final variables as actually final. Security can suffer as well when a lack of encapsulation can be used to read or even write important information in critical pieces of code - I link an example for this as well.

This situation became untenable and so, in 2017, JDK 9 introduced strong encapsulation, which prevents the access of module internals. And of course all JDK code got moved into modules. But you still had to opt in - it wasn't until JDK 16 in 2021 that strong encapsulation became the default.

So now, JDK code as well as all other code that runs in explicit modules, can by default rely on strong encapsulation and thus the integrity of visibility modifiers, for example. But, if that's important, we can still opt out! The command-line options --add-exports and --add-opens allow us to define targeted exceptions from this rule.

Unsafe

Whoever named Unsafe, really hit the nail on the head. This class is basically just a collection of backdoors into Java's innermost promises. Visibility, finality, memory safety, and probably a few more could all be violated with sun.misc.Unsafe. Which is why it's not surprising that it has been chipped away at for a few years now. Step by step, new APIs that either don't undermine Java's integrity or require opt-in - more on that in a second - have replaced Unsafe's functionality, which could then be deprecated and eventually removed.

The most recent example of this is JEP 471: Unsafe's memory-access methods were superseded by var handles in JDK 9 and the foreign memory API in JDK 22, and so in JDK 23 they got deprecated for removal, which is currently projected to happen no sooner than 2026.

Native Code

The Java native interface and the foreign function API both allow execution of native code. There's of course nothing wrong with that in general but it's outright harrowing in the context of integrity because native code can, and this is the technical term, do whatever the duck it wants: corrupt memory, cause undefined behavior, sidestep visibility checks, change private and final fields, and so on. That said, the technology used to launch native code has some influence on these vectors and FFM is generally more restrictive than JNI. Furthermore, FFM classifies its integrity-undermining methods as restricted and requires the command-line option --enable-native-access to execute them.

And now, JNI is herded along the same path. JEP 472, which is currently proposed to target JDK 24, wants to make the loading and linking steps in JNI trigger a warning by default, which can be prevented by that same --enable-native-access option. In the long run, it wants those operations to throw exceptions if the option is absent. At that point, we can be sure that a Java program's integrity isn't violated by native code as long as that option is absent.

Agents

Agents are a class of Java components that are attached to a running application and use Java's instrumentation API to read and potentially modify the application's bytecode. It should be immediately obvious how this does not gel well with integrity. An agent could, for example, make the int field that we earlier wanted to be non-negative public and thus void the class' integrity. Or it could just change the constructor's code to set the field to -1, or something.

// source-code equivalent
// of the byte code after
// the agent changed it
public class Counter {

	// whatever 🤷
	public int count;

	public Counter() {
		count = -1;
	}
}

And, again, we're seeing a push to disallow this by default and require a command-line option to unlock this capability. In this case, it was JEP 451, which made the JDK 21 issue a warning when an agent was dynamically loaded unless the option -XX:+EnableDynamicAgentLoading (I guess) was used and which proposed to turn that warning into an error at some point in the future.

Integrity By Default

So, in the end, we'll get similar behavior across all operations that can undermine integrity:

they're off by default and trying to execute them will cause an exception
there are command-line options to enable them
and, where applicable, these options allow us to only enable the feature for specific modules, meaning just because you unlocked, say, native access for a thoroughly verified dependency you're not automatically doing the same for all other dependencies

An important reason why this is all managed with command-line options is that the only people who can decide whether a feature is worth the loss of integrity are those running the application because they will suffer the potential fallout. No library and no framework developer should be able to decide (and quietly!) for all their users that application integrity is worth less than whatever their project offers. Having to tell users that they need a command-line option to make use of a project is not an accident, it's the intended effect of restricting and allowing access like this.

Consequently, if none of those command-line options are present, you can fully rely on Java's integrity. That becomes increasingly important for the platform itself as more and more of it is written in Java instead of native code. But it's also important for us because...

Integrity increases the maintainability of modules as their internals can't be depended upon. This makes life easier for OpenJDK and 3rd party developers but also for application developers who can more readily update dependencies as those can't depend on frequently changing internal APIs.
Integrity is a cornerstone of security as strong encapsulation allows us to isolate vulnerable code and to limit how much it can be used to escalate an attack.
And it improves performance when optimizations can rely on invariants to actually be invariant - something Project Leyden is particularly interested in.

Even with those benefits from integrity, it's worth pointing out that an operation isn't "evil" just because it undermines it. Reflection, native access, agents, etc. - they all have their use cases and are important parts of the Java ecosystem. But, remember, with great power comes great responsibility, and so it's important to have these features off by default and then judiciously enable them exactly when needed - and that's what integrity by default provides us.

I hope I did a good job of condensing the JEP draft into this short video, but there's definitely a ton of background information, explanations, and insights that I had to skip, so if you're interested in this topic, please give it a read - the link is of course in the description. If you think I did do a good job, leave a like - that makes me happy and puts this info in front of more developers' eyes. I'll see you again in two weeks - so long...

Watch the video.

Java and AI - A Structured Analysis

Nicolai Parlog — Fri, 12 Jul 2024 00:00:00 GMT

What AI development needs and how much Java already has to offer, what it lacks, as well as what it's poised to acquire in the future

"AI in Java is bad" ... is a commonly held opinion. But one that is, as I will argue in this talk, overly influenced by our current place in the AI timeline. It overlooks the already dawning reality that a big chunk of AI-related development work will be the addition of AI-based features to other, larger projects.

There, Java is already very competitive and will only become stronger in the coming years thanks to the work in OpenJDK projects Panama, Babylon, and Valhalla and even Amber and Leyden plus dozens of great projects in the wider community that make AI development in Java natural.

So let's discuss what AI development needs and how much Java already has to offer, what it lacks, as well as what it's poised to acquire in the future.

PS: I'm a Java fanboy, not an AI expert - bring pinches of salt.

JDK 23 Removes COMPAT Locale Provider

Nicolai Parlog — Thu, 11 Jul 2024 00:00:00 GMT

With the removal of the JDK's own (somewhat outdated) locale data, all projects must now use the CLDR data or other implement a custom locale data provider

A Quick History of Locale Data in the JDK

Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014:

JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers:
- JRE/COMPAT for the JDK's legacy data collection (default)
- CLDR for the CLDR data
- a custom locale provider can be implemented
JDK 9 picks CLDR by default
JDK 21 issues a warning on JRE/COMPAT

There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 lists a few of them.

Locale Data in JDK 23

JDK 23 removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect.

Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain:

Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed.
Implement a custom locale data provider.

For more details on that as well as on CLDR in the JDK in general, please check JEP 252. It has been recently rewritten to provide better information and guidance.

Java and AI? - Inside Java Newscast #72

Nicolai Parlog — Thu, 04 Jul 2024 00:00:00 GMT

AI development can be split into three categories: developing an ML model (where Java isn't competitive and is unlikely to become top of the class any time soon), developing an AI-centered product (where Java is well-positioned and will become stringer soon; but does this category matter in the long run?) and adding AI-based features to larger projects (where Java is already very good and will only become stronger thanks to Valhalla's value types, Panama's FFM and vector APIs, and Babylon's code reflection).

"AI in Java is bad" is a commonly held opinion out there that I, without knowing much about this space, grudgingly accepted. But, being a Java fanboy I was annoyed by that and I was waiting for Valhalla, Panama, and Babylon to make sufficient progress, so I could make a video about how AI in Java may suck now, but will be so good in the future. But that's not this video! When I recently started looking into the topic, I realized that "AI in Java is bad" is a pretty myopic view that, if it's correct at all, really only applies to this very moment in AI development and that Java is already well-positioned for the future of AI. And on top of that come Valhalla, Panama, and Babylon. Let me explain.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna look at Java and AI. A quick note before we start: I know that artificial intelligence is more than just machine learning, but since the current AI wave is basically exclusively ML-based, I'll use the terms interchangeably in this video. Ready? Then let's dive right in!

Three Kinds of AI

I want to split AI development into three categories.

The first one is developing a machine learning model. Collecting data, preparing it for learning, developing and training the model, evaluating and iterating on it - all the "original" machine learning tasks. The output is a trained model that can classify inputs, generate images or texts, deny people life choices for inscrutable reasons, start nuclear war, etc.

Then there's executing a machine learning model based on some inputs. Note that trained models can be exported and imported by different languages, so this can be done on an entirely different platform than was used to train the model. And thanks to a distinction MKBHD made me aware of, I want to split execution into two categories.

One (and the second overall category) is development of a product centered around such an ML model, like ChatGPT or the Humane AI pin. This is mostly regular greenfield software development, except that requirements for running these models, like availability of ML libraries or ease of pushing computations onto the GPUs, dominate the overall requirements.

The other (and third) category is integration of a machine learning model as a feature into larger, often pre-existing products. Think of auto-tagging and searching in Google Photos, auto-subtitling in PowerPoint, and pretty much everything Apple has just presented at WWDC. Here, AI is just one of many requirements, one of many forces acting on the project and in the case of brownfield development (what a word), these forces and the path of least resistance are mostly known and running the model must fit in with the existing architecture.

Let's look at each of these three categories separately and see how suitable Java is for them and what features may improve it. We'll start with the last one and work our way backwards from there.

AI Features in Java

The easiest case for AI in Java is when model execution needs to be added to an existing Java project. Of course, in many situations you could create a new service in an arbitrary language, and incorporate that in your project via a REST API or as foreign code, but, realistically, you'd probably try to avoid that due to the developmental and operational complexity. In this scenario, Java doesn't need to be the best ecosystem for executing the model, it just needs to be better than using a different one minus the additional effort of having it as a separate service and platform.

And similar logic applies when creating a new project where AI is just one of many features. Java may not be the best ecosystem just for model execution but it is really strong and often top of its class in many other important development aspects: strong typing, good abstractions and core library, memory safety, performance, observability, security, cloud support, web server and framework choice, 3rd party library choice in general, development speed, developer base, stability, and the list goes on and on.

All that puts Java high up on the list for projects that include AI-based features assuming its support for model execution is sufficiently good. So how good is it? On the library and runtime front, Java offers a number of strong options: TornadoVM, ONNX Runtime, DJL, Tribuo, LangChain4j, just to name a few. Many already support multi-CPU, GPU, and even FPGA-accelerated computation and, where applicable, we can expect their integration with native libraries to improve due to the recent finalization of the foreign-function-and-memory API.

And some OpenJDK projects are working on features that will further improve Java's capabilities in this space, potentially dramatically, and particularly when it comes to executing models in pure Java:

Project Valhalla aims to give us the capability to define types that "code like a class, work like an int", which is relevant here because models like to use primitives like half-floats that Java currently doesn't support. Beyond that, Valhalla will allow us to write performant code that doesn't have to sacrifice good design and maintainability, which is essential for every software project that will run in production for anything longer than a few months. And another idea Valhalla might, might (!), MIGHT (!) explore is limited operator overloading, which may allow us to define, for example, multiplication for custom scalar... scalars? Scalars? Sc... tensors and sca, scalars. That's what you get for studying math in German. Skalare. Anyway... for custom scalars and tensors.
Then there's Panama's vector API, which can speed up CPU-based computations dramatically.
And finally, and most directly aimed at AI, there's Project Babylon. Its goal is to allow Java code to parse other Java code and derive new code that could either be a different Java program or any kind of foreign code, in this context specifically, code that can be executed by a GPU. I strongly recommend Inside Java Newscast #58 for a primer on Project Babylon. As part of his work on the project, its lead Paul Sandoz explored how to implement Triton (that's a domain-specific Python platform for GPU computation) in pure Java and got really good results.

Embedded video.

So the Java ecosystem for executing ML models is already pretty strong and Valhalla's value types, Panama's FFM and vector APIs, and Babylon's code reflection will only strengthen it further, whether by better integrating with native code or by enabling pure Java implementations with similar performance, giving projects the benefit of using just one stack for the entire system or service.

Of course even if we ignore the rest of the application and focus on just running a model, the code that does that consists of more than calling predictor.predict. Input data needs to be prepared before it can be thrown at the model and, likewise, its output needs to be interpreted and transformed into something the user can understand. This is likely to be a considerable portion of the overall code for model execution and Java's strengths apply here as well, particularly its good performance characteristics and its recently improved support for designing data-centric applications. So, yeah, I'm not worried about Java when it comes to projects using AI as a feature.

AI Products in Java

Most of what we just discussed also applies to developing an AI-centered product in Java. But of course, the larger the AI portion, the more strengths and weaknesses in that area dominate the overall evaluation of which platform to use. At this moment, is Java the best for just running an ML model? No. Is it the best for developing an AI-centric product once we factor in the surrounding requirements we talked about in the previous section? Maybe, it's definitely up there. Will it be the best once all the projects I mentioned earlier bear fruit? I think it can be, yes.

But here's a more interesting question: Does it matter? I really liked MKBHD's opinion on this and, by the way, the link to his video as well to everything else I mention here is of course in the description. He makes a good argument for "AI as a product" being mostly a fad. For AI becoming mostly "just" a feature in all kinds of other applications. So as it looks now, I don't think this category is particularly important.

AI Development in Java

Which leaves us with the last category: developing machine learning models in Java and his is a tough one. It needs everything we described so far and then some.

AI development is often done by people who don't see themselves as being primarily a software developer and so they value different things about a platform than other developers might:

ease of learning the language
example code bases are always very important
how quick you get to the first usable results
simplicity over choice
and also (occasionally or maybe even often) simplicity over robustness

If certain language features only become beneficial when you maintain a project of sufficient size for a sufficient time but appear to be in the way early on, enforcing their use can quickly be seen as a downside. Looking at you, explicit static typing and checked exceptions. Thanks to Project Amber's on-ramp efforts, Java made and will keep making significant progress in this area, but it will never be a scripting language.

More importantly, though, elegant model development requires a number of specific language features and libraries:

a type system that can easily handle heterogenous data
some degree of operator overloading is super helpful
ease of use when working with mathematical functions (for example for differentiation)
libraries that were designed to classify and analyze large data sets
and really good and easy-to-use visualization tools

And Python is and will probably remain king here. The language is well-suited to these kinds of applications and thanks to that has been the platform of choice for data scientists for about two decades now, which gives it a big leg up on libraries and frameworks in that space.

So Java isn't competitive when it comes to developing machine learning models and isn't top-of-the-class in creating AI-centered products and this lead to the general opinion that "AI in Java is bad". But this is due to our current place in the AI timeline and overlooks the already dawning reality that a big chunk of AI related development work will be its integration into other projects and there Java is already very competitive and will only become stronger in the coming years, thanks to projects like Valhalla, Panama, and Babylon.

If you want to follow that development along, make sure to subscribe if you haven't yet, as we will cover every new Java feature as it hatches. And if you enjoyed this video, you can do me a favor and leave a like, which also helps putting it in front of more developers. I'll see you again in two weeks. So long...

Watch the video.

Why Update Data-Oriented Programming to Version 1.1?

Nicolai Parlog — Wed, 26 Jun 2024 00:00:00 GMT

A review of data-oriented programming version 1.1: What caused the update and what is still left to be improved?

We just concluded a six-part and seven-thousand-word article series on version 1.1 of data-oriented programming in Java, which went deep into the paradigm as well as the language features that are best used to implement it. It left one question unanswered, though: Why did we need an update to 1.1? In what way does it hope to improve the original proposal? And as a follow up to that: What are the shortcomings of 1.1 and what could a version 1.2 do better? I'll share my thoughts on that in this bonus article. 😃

Version 1.0

Brian Goetz laid out these four guiding principles in his seminal article Data-Oriented Programming in Java:

Model the data, the whole data, and nothing but the data.
Data is immutable.
Make illegal states unrepresentable.
Validate at the boundary.

After implementing a few (small) projects following these guidelines and communicating them in various talks and videos, I started to see room for improvements. Less with the guidelines themselves and more with the way they're formulated:

Three of these statements are normative, but "data is immutable" is descriptive. This is not only inconsistent, a factual statement is also not suitable as a guideline.
The guidelines don't mention transparency, which is essential for implementing operations outside of the classes modeling data. It was also a driving force behind records' built-in transparency, so I thought it should get a mention.
Another important aspect I found underrepresented were operations. While Brian explains in details where to place and how to implement them, that advice is not explicitly captured in a principle.
Making illegal states unrepresentable and validating at the boundary are very closely related.
The principles don't have equal weight. When presenting them, the majority of the time is spent on "Model the data, ..." (which was also the principle that implicitly included how to handle operations) after which the remaining three guidelines can be ticked off in short order.
In general, I didn't find these principles sufficiently orthogonal. The order in which they are presented greatly influences how much there is to say about each of them, which shows that they're very dependent on one another.

As you can see, I didn't (and don't) have any issues with the building blocks of data-oriented programming. I just felt that their organization into four principles and their headers could be improved.

Version 1.1

To remedy the issues described above, I made the following changes:

Turn "Data is immutable" into a normative statement and add transparency. This makes it the perfect vehicle to talk about records.
Make the resulting guideline the first one, so it can discuss records in isolation before going into other features.
Subsume "validate at the boundary" under "make illegal states unrepresentable" by making boundary validation part of the strategy to achieve unrepresentable illegal states.
Add a guideline for operations.

This leads to:

Model data immutably and transparently.
Model the data, the whole data, and nothing but the data.
Make illegal states unrepresentable.
Separate operations from data.

Version 1.2?

But I'm still not entirely happy with the result:

Orthogonality barely improved. In fact, that I changed the order of the first two principles just shows how much they still depend on one another.
The weight distribution improved but is still a little out of balance. Using word count as a proxy, we can see that operations are three times heavier than preventing illegal states (2.6k words vs 0.8k words), although that comes in part from the lack of orthogonality: The article on illegal states is only so short because I already covered in earlier articles how to prevent many illegal combinations with sealed types and records.
"Model the data, the whole data, and nothing but the data" sounds very cool, but it's not particularly evocative nor precise. In fact, you can talk about pretty much anything under that header. I wonder whether this is one of those darlings that writers have to kill occasionally.

There may well be more issues with the new version, in which case I'm sure that further experimentation with or exposure to data-oriented programming will flush them out. If there's anything you think could be improved, please reach out to me - I'm nipafx everywhere.

Article Series

Data-Oriented Programming in Java - Version 1.1
Model data immutably and transparently - DOP v1.1
Model the data, the whole data, and nothing but the data - DOP v1.1
Make illegal states unrepresentable - DOP v1.1
Separate operations from data - DOP v1.1
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1? (this article)

What Happened to Java's String Templates? Inside Java Newscast #71

Nicolai Parlog — Thu, 20 Jun 2024 00:00:00 GMT

JDK 23 doesn't contain the string template preview that was present in JDKs 21 and 22. Let's discuss why the feature was removed (probably not for the reasons you think), what a new proposal could look like, and when we may see it.

And just like that, string templates are gone! What happened here? Was it because of the syntax? Will string templates come back and when? Let's talk about it.

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about the withdrawal of the string template preview from the JDK - from a technical point of view but also what that tells us about the development process and when we may see a new proposal. Ready? Then let's dive right in!

Why String Templates Are Out

JDK 21 and 22 previewed string templates, a language feature that makes it easier to safely embed variables in structured languages like SQL, HTML, JSON, etc. I assume you know its outlines and understand how it embedded variables and how it required template processors to turn those templates into strings or other arbitrary objects. If you don't, here's a video that will fill in the gaps.

From its first days, the proposal caught some flack. Lots of people took issue with its use of \{} instead of something they're more familiar with (like ${}) to embed variables and we'll get back to that later. There were also qualms about its special syntax for processor invocations (the $processor.$template syntax), which was just sugar for a regular method call to the processor's process method.

Then there are a few things that turned up when using the feature in practice, for example within jextract. One is that template processors often don't quite cut it, for example due to the intentional limitation that they need to return something. And in those cases, it would be super handy to just pass the string template to a method but that required the special processor RAW, which wasn't exactly elegant. Nesting templates also wasn't really supported but would be very handy. And, lastly, when designing or evolving text-based APIs, developers would have to choose between methods accepting strings or template processors, two very different approaches.

Brian Goetz summarized this as "the real criticism here is that template capture and processing are complected, when they should be separate, composable features".

// TEMPLATE CAPTURE
// creating a string template
// (e.g. to assign to a variable)
StringTemplate t = // ...

// TEMPLATE PROCESSING
// turning the template into something else
// (often a string, maybe an SQL query)
Statement query = SQL.process(t);

// EXAMPLE OF COMPLECTION
// must apply a processor, even
// if just to get the template
StringTemplate t = RAW."template";

But that intertwining wasn't an accident. A background design goal of string templates was to bring the abysmal performance of string formatting on par with string concatenation. The template processor FMT accomplished that because it got access to an internal API, was highly optimized, and occurred right next to the string it was supposed to format. That last point turned out not to be a requirement for a fast implementation, after all, and so the template and the code processing it don't have to appear side by side, after all.

This was the straw that broke the processor's back. It turned out, processors aren't needed right there next to the template, which means they don't need a special syntax to be usable and the string template processing can happen in just any arbitrary method. This unravelled a lot of already-settled design decisions and basically sent string templates back to the drawing board.

Current State in JDK 23

All of this came to a head in March, when Brian Goetz sent a mail to an Amber mailing list recounting this development. This triggered a super-interesting discussion but it's length and breadth indicated that this issue wouldn't be solved in the remaining 12 weeks or so before JDK 23 would be branched and so the decision was made to remove string templates entirely. And as we've touched on in the last Inside Java Newscast, that's exactly what happened: JDK 23 contains no string templates at all and once you update your experimental and hobby code bases, you'll have to rip out everything related to string templating, which isn't particularly fun.

Embedded video.

Talking about not fun. I'm not entirely healthy right now, you might hear it in my voice, and I'm a bit unfocused, too. Haha, very funny. But it's not bad enough to call in sick and I really wanted to let you know about string templates, so I recorded the video anyway. That said, I didn't quite manage to keep the script short and I also don't want to spend an inordinate amount of time editing the remainder of the video, so to keep it lively, I'll just record in different rooms around my flat. What do you think about that? Doesn't matter, I'll do it anyways.

String Template Future

So what's going to happen next with string templates? Before we delve into that, keep in mind that nobody can predict the future. What follows is based on the discussions on the mailing list, specifically the exchange in early March, but as you can tell by what just happened, nothing is set in stone.

Ok, with that out of the way, there are a few things we should examine:

the string template goals
security vs simplicity
the dollar sign
the most elegant solution
open questions
future timeline
what this means for OpenJDK

Let's get into it!

String Templates Goals

Probably most importantly, none of the experiences made during the preview phase changed the goals that string templates set out to achieve:

simplify and improve readability of combining strings with values computed at run time
improve the security of such mixed expressions by supporting validation and suitable transformation
enable transformation to non-string values that doesn't require an intermediate string representation
allow non-JDK code, like in libraries or applications, to seamlessly hook into this mechanism

An essential observation is that these goals don't include "make string interpolation as simple as possible". In fact, this is explicitly listed as a non-goal - quote:

It is not a goal to introduce syntactic sugar for the string concatenation operator, since that would circumvent the goal of validation.

Let's talk about that next.

Security vs Simplicity

Why don't you just add string interpolation like all those other languages have. Stop overcomplicating everything!

... is a common opinion on this topic. But, and how do I put this delicately, it's not on point. Not because of the intention - I get that string interpolation would be nice to use. But because of its superficiality.

Nobody needs to be saved from having to type a + between a string and a variable. But in the most recent OWASP Top Ten, injection attacks are in third place (down from first place in the previous ranking, btw). This is clearly a serious problem for our industry and regularly causes the loss of sensible user data, legal challenges, and significant financial damages. This is a problem worth tackling, not the +.

But if it's all about security, why do the goals mention simplicity and readability? Well, first of all: Don't get me wrong, it would be really nice to get rid of the +, so I'm all in favor of exploring the options there. But more importantly, if the new approach is safer than concatenation but less elegant (even less elegant), there will always be a tension and developers will always tend towards the unsafe option. So making it more elegant than concatenation will avoid that tension and make us want to use the safer option. But to achieve that, it doesn't need to be the most elegant solution - just elegant enough.

And it's important to think about this holistically. Python Enhancement Proposal 498 introduced literal string interpolation to Python. PEP 501 starts by pointing out that code using it is "superficially elegant" but also "an opening for a form of code injection attack". It then proposes a new kind of expression and an InterpolationTemplate type that look very similar to the string template previews in JDK 21 and 22. So did Python copy Java here? Eh no, all this went down in 2015 and while Python does have interpolation since then, it never got around to retrofitting a safe alternative. Oops - better to think about this upfront, I guess.

So that's why we won't get, I don't know... String s = ``text $variable``; Oh, and I'm pretty sure we won't get $ for embedding variables either. Let me burst that bubble next!

🤑🤑🤑

So I know that quite a few people weren't very happy with the \{} syntax to embed expressions. They're used to $ or ${} from some other languages and want to see the same in Java. But while familiarity is a good reason to examine a potential solution, it's not a good reason to adopt it. And really, there's nothing in favor of $ except familiarity.

Well, some people say it's hard to type \{ on their keyboard but given that curly braces are ubiquitous in Java and the backslash isn't exactly rare either, I don't think this argument is very strong. And, for what it's worth, on my German keyboard, \{ is simpler than ${. Maybe that makes me biased, I don't know.

Anyway, there are two main arguments against the dollar sign:

If it becomes a special character in string templates, it needs to be escaped to appear as-is, and given that it's quite common, that would be annoying.
Turning a string into a string template or the other way around would then require carefully updating a bunch of dollar escapes even though they are entirely unrelated to any interpolation that the developer is probably thinking about right now.

I also want to point out that of the top 10 TIOBE languages, only JavaScript actually embeds expressions with a $, so... I don't know, doesn't seem to be that common after all.

The main arguments for \{} are that \... is already an established escape mechanism (so why add another one?) and that \{ is a currently illegal character sequence, which means it's not present in non-template strings, doesn't need escaping, and the compiler will yell at you when you switch from a template to a regular string. And based on these arguments, Brian describes \{} as "objectively better" than the dollar sign, so I'm pretty sure that's what we'll end up with.

Ok, any more dreams I can crush? Oh, yeah, the old solution was too cumbersome, we need something more elegant!

Elegance

Right, so a few folks found STR."text \{variable}" too cumbersome, specifically the STR. part. If you're one of them and were happy that this proposal was retracted, I'd recommend to curb your enthusiasm - I don't think the next proposal will be leaner than that.

So here's the thing: The STR. syntax was essentially just a shortcut for calling STR.process() with the string template as an argument, right? This was done so the template and its processor must appear side by side, which was considered necessary to make FMT faster than String.format due to some internal optimization that I don't understand. Since it now appears possible to achieve that performance improvement by other means, without those having to appear side by side, that special syntax no longer carries its own weight - we'll probably end up simply creating a string template and then passing it to a method.

So string templates could just be a new kind of literal, although it's unclear what exactly they would look like. To have something to talk about, let's say they use backticks as delimiters. Then a simple interpolation could be something like String.interpolate(``text \{variable}``). That's less weird but longer than that STR., so... yeah, don't hope for a shorter solution is all I'm saying.

Open Issues (and Timeline)

(Yep, this is my bathroom. Yep, we are doing this.)

So as I just described, a new proposal will:

favor security over the simplest possible interpolation
will very likely use \{} to embed expressions
will probably get rid of any syntax sugar and require regular method calls to process templates

Still, there are a lot of open questions to be answered and they may well shape the feature in entirely unforeseen ways. For example:

What would APIs look like in the future? Regular methods accepting strings and or string templates presumably? A few security-sensitive APIs may limit themselves to just templates, but many more would be ok with either - do they all need overloads?
What marks a string template? In the retracted proposal that was the template processor, but with that out of the picture, does something else need to take its place? It would be nice to be able to seamlessly create a template without variables, specifically for those APIs that only accept a template.
And what about concatenating and nesting templates? Should that be possible or specifically supported?
Another one is: Should String extend StringTemplate or the other way around? Or maybe string literals can be either?

All of these and more have been discussed at length in that thread back in March and I can only recommend to check it out if you want to have an informed opinion on these matters. But these and more questions need to be answered before a new proposal can be made. And since the main goal is to improve security in Java, all answers will have to be measured by that metric.

And just so it has been said, I don't think it's guaranteed that we'll see string templates in Java in the future. If there's no solution that's both safer and elegant enough (in terms of usability, migrations, etc.), then maybe we'll be stuck with +. And as a corollary to that observation: I have no clue when we'll see another proposal, but just personally, I'd be somewhat surprised to see a JEP on this in 2024.

The Preview Process

(Yeah, I'm back here. Sorry I ran out of ideas. But, hey, I changed the colors.)

While opinions on the proposal varied, sometimes widely, most comments I saw were generally appreciative of the fact that the OpenJDK developers are taking the time to get this right and that they made the surely-not-easy decision to retract the proposal this late in the game instead of just letting it get over the finishing line in a state they didn't think was optimal. And I agree with that! Yeah, I liked the proposal. And I have to rework quite a bit of code to pull templates out and then, hopefully, put them back in in a few months. Still, if the folks behind this think they can make it better, I'm inclined to trust them and see what the next proposal will be.

In fact, I think this is a great example of the process working as intended. Preview features are here to be used in practical experiments (internally or externally) without the wider community relying on them. This allows OpenJDK to identify weaknesses and, if necessary, correct course or even scrap a proposal entirely. So that's all good.

Still, I know we were all kinda surprised that this happened. I mean, in over five years, I think, it's the first preview feature that didn't become final. While that was always possible, it didn't feel quite real. But it is! So let this be a reminder: Preview features can change, evolve, or be dropped - just like the JEP that introduced the concept points out.

Talking about JEPs: Preview features are impermanent and do not carry over from one Java release to the next. Even if unchanged, a new JEP needs to be filed for the next release to include the feature. As an unfortunate side effect of that, people who limit their reporting on a new Java version to the JEP list, won't give you the full picture as they would miss cases like this. But that's easily fixed: Just get your Java info from people who know what they're talking about!

That was your cue to subscribe to this channel. I meant us, I mean... it doesn't matter. Don't forget to leave a like as well and I'll see you again in two weeks. So long ...

Watch the video.

JDK 23 Changes Default Annotation Processing Policy

Nicolai Parlog — Tue, 18 Jun 2024 00:00:00 GMT

Starting with JDK 23, annotation processors in the class path will no longer be executed without further javac configuration

Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing.

New `-proc` Value

To that end, the pre-existing option -proc:$policy was extended, where $policy can now have the following values:

none: compilation without annotation processing - this policy exists since JDK 6
only: annotation processing without compilation - this policy exists since JDK 6
full: annotation processing followed by compilation - this policy is the default in JDK ≤22, but the value itself is new (see next section for versions that support it)

Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither -processor, --processor-path, nor --processor-module-path is used, -proc:only or -proc:full has to be provided. In other words, absent other command line options, -proc:none is the default on JDK 23.

Migration to `-proc:full`

Several measures were undertaken to help projects prepare for the switch to -proc:full:

As of the April 2024 JDK security updates, support for -proc:full has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports -proc:full.
Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected.

With -proc:full backported, it is possible to configure a build that will work the same before and after the change in javac's default policy.

More Details

This is a summary, for more details make sure to read the original proposal.

When to use Data-Oriented Programming

Nicolai Parlog — Mon, 10 Jun 2024 00:00:00 GMT

How does data-oriented programming compare to object-oriented and functional programming and what are good situations to start using it?

In this sixth and last article in the series about data-oriented programming v1.1, we're wrapping it up with a review of data-oriented (DOP) versus functional (FP) versus object-oriented programming (OOP). First, let's briefly summarize what the four guiding principles left us with:

Use types to represent data:
- Model data transparently and immutably (usually with records).
- Model alternatives with sealed interfaces.
- Model the data as closely as possible and only represent legal states.
Implement operations as methods on other classes:
- Use exhaustive switch statements, predominantly over sealed interfaces and without a default branch.
- Use pattern matching to identify and decompose data.

If you want to read up on the details, find the other articles here:

What Java Version Do You Need?

Before we go into DOP and how it compares to FP and OOP, let's briefly examine on which Java versions it works best. While records and sealed types are present in JDK 17, the just-as-essential patterns in switch weren't finalized until JDK 21, which makes it the minimum requirement for data-oriented programming.

The single underscore as unnamed pattern was finalized in JDK 22 but while very helpful and elegant, it's not a requirement. Its absence can be worked around by repeating "defaulty" branches (remember, avoid outright default branches!):

switch(item) {
	case Book book -> createTableOfContents(book);
	case Furniture unused -> { }
	case ElectronicItem unused -> { }
}

DOP versus FP and OOP

In functional programming, all operations are pure functions, which have data as input and output and don't produce any side effects - appropriately composed, they implement the logic of the system. This works if you concentrate all mutable parts of a system in dedicated subsystems (e.g. the user interface in the client and data storage in a database) and view the stateless remainder of the system as a function that mediates between the other subsystems (e.g. user input and the current state of the database map to instructions for changing the interface and the database). This approach can be particularly effective for web applications and can lead to very maintainable code.

In many projects, however, it turns out to be difficult to achieve or maintain this absolute statelessness and absence of side effects. From the team's experience in functional programming to the suitability of the language, from functional and performance requirements to the availability of libraries and frameworks that support this approach, challenges abound.

The strength of functional programming isn't the panacea that awaits you if you follow all the rules to the letter, though, but that its approach works very well even on a small scale. Any piece of domain logic represented as a function - be it a simple stream pipeline or a chain of handwritten functions - makes the code base more reliable and usually more maintainable, too.

Data-oriented programming takes advantage of this fact and proposes a structure that favors functional purity wherever possible and isolates necessary deviations as far as possible in the subsystems responsible for the corresponding logic. DOP is therefore between FP and OOP, but overall closer to the former.

But object-oriented programming is not dead (again). The tools of encapsulation and inheritance, the ease with which large problems can be modularized (that is, broken down into small problems that are mostly isolated from each other), and our familiarity with this programming paradigm continue to make it valuable. So I have no intention to recommend a fundamental switch from OOP to DOP (or FP). Instead, we should see DOP as an additional tool that we can apply in appropriate situations.

When to Use DOP

Similar to functional programming, the advantages of data-oriented programming can be felt even on a small scale. The use of records, the prevention of mutation, the avoidance of placing complex operations on data, the clarity of switch over the visitor pattern - any piece of code that uses these techniques in the right environment will be clearer and more maintainable than without them. It is therefore not necessary to develop entire systems in a data-oriented manner.

If you want to start on a small scale, you should look out for two situations:

data processing (sub)systems
small (partial) problems that do not require further modularization

Well suited are, for example, systems that directly ingest and output data (e.g. batch jobs or data analysis tools), process events (where the events would be "the data"), or model an existing structure to allow its manipulation (the structure would be "the data", manipulation would be achieved via functional transformation - see for example the new class file API in JEP 457). This can be a small, stand-alone service or part of a larger system.

From my own experience I can say: Once you've used data-oriented programming and experienced the concepts in practice, you'll soon start to see small and large use cases everywhere, and so far I've always been very happy with the results. The code is readable thanks to the separation of data and operations, both can be easily verified and tested individually, and the overall architecture is easy to understand.

To everyone who has become curious after this (thorough) introduction and will soon be using DOP: Good luck, have fun! 🍀

All Java 23 Features - Inside Java Newscast #70

Nicolai Parlog — Thu, 06 Jun 2024 00:00:00 GMT

Java 23 will be released on September 17th but it's branched today (June 6th 2024) and so its feature set is final. Generational ZGC, Markdown in JavaDoc, deprecations in Unsafe, the removal of string template, and the thoughtful evolution of eight preview features. Let's take a closer look!

It's release branch day! Later today, the JDK repo will get the new branch jdk23, which is simultaneously business as usual and a small novelty - I'll explain later what I mean by that. Either way, the JDK 23 features are set in stone, so let's take a look.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna go over all the changes JDK 23 brings to Java. Truth be told, the list of final features is a bit slim, so let's start with the meatier preview features. Ready? Then let's dive right in!

Previews

Primitive Patterns

There are two ways to summarize JEP 455. The short one is: It allows primitives in patterns, which means you can now switch over or instanceof-check a primitive float, double, etc. and get more options when switching over int and long. While that may seem borderline pointless at first, it has a few unexpected benefits in the present and in the future.

// in `switch`
switch (Rank.of(book).current()) {
	case 1 -> firstPlace(book);
	case 2 -> secondPlace(book);
	case 3 -> thirdPlace(book);
	case int n when n <= 10
		-> topTenPlace(book, n);
	case int n when n <= 100
		-> nthPlace(book, n);
	case int n -> unranked(book);
}

// in `instanceof`
jshell> boolean is216float = 16_777_216 instanceof float
is216float ==> true
jshell> boolean is217float = 16_777_217 instanceof float
is217float ==> false

The longer summary is quite a bit longer because it goes far afield to explain why this is pretty cool actually. Go check out Inside Java Newscast #66 for all of that or just straight-up read the JEP.

By the way, there are links in the description to more details on every feature I mention, so go check them out if you want to dig deeper into any of them.

Primitives in patterns have their first preview in JDK 23 and if there's only one feature you want to put to the test, make it this one, and take your learnings to the Amber mailing list.

Embedded video.

Flexible Constructor Bodies

To make sure that object initialization works correctly across class inheritance and multiple constructors, a constructor calling another one must do that as its first statement. Or at least it had to.

JDK 22 started previewing looser rules by allowing statements that would compile in a static block before such a this() or super() call. Now, JDK 23 goes a step further and also allows assignments to fields in the same class. In this second preview, the feature has also been renamed to flexible constructor bodies.

class Name {

	private final String first;
	private final String last;

	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

}

class ThreePartName extends Name {

	private final String middle;

	// JDK ≤21
	ThreePartName(String first, String middle, String last) {
		// shorten first if middle is given
		super(middle.length() == 1 ? first.substring(0, 1) : first, last);
		this.middle = middle;
	}

	// JDK 22 + PREVIEW FEATURES
	ThreePartName(String first, String middle, String last) {
		// shorten first if middle is given
		var short1st = middle.length() == 1 ? first.substring(0, 1) : first;
		super(short1st, last);
		this.middle = middle;
	}

	// JDK 23 + PREVIEW FEATURES
	ThreePartName(String first, String middle, String last) {
		// shorten first if middle is given
		var short1st = middle.length() == 1 ? first.substring(0, 1) : first;
		this.middle = middle;
		super(short1st, last);
	}

}

Embedded video.

Simplified Main

The simplified launch protocol sees its third preview with two additions. As before, it allows you to write a Java source file that only contains a void main() method - no args, no static, no public, not even a surrounding class, although you can add all of that if it's needed. If you don't type out a class, one is implicitly declared for you and this is where the two additions come in.

First, an implicitly declared class implicitly imports the three methods on the new class IO in the java.io package. Those methods are print, println, simple wrappers around the same methods on System.out, and readln, which takes a string that it prints as a prompt and returns whatever line the user typed as a reply, which is so much simpler than the "new BufferedReader of new InputStreamReader of System.in"-dance. This will make it much easier for beginners to interact with the terminal, a classic early step when learning to program.

// complete source file; executable with:
//     java --enable-preview Main.java
void main() {
	var planet = readln("What planet are you on? ");
	println("Hello, %s!".formatted(planet));
}

The other addition is also an import, because implicitly declared classes now implicitly import the module java.base.

Embedded video.

Module Imports

Yes, as discussed in the last Inside Java Newscast, JDK 23 previews module imports. When importing a module with import module $modulename, all public types in all packages that are exported to you via that module are available to you. This is particularly handy when coding outside of an IDE or when just starting out with Java. And with implicitly declared classes implicitly importing java.base, many simple programs will get away with zero explicit imports.

// complete source file; executable with:
//     java --enable-preview Main.java

// implicit: `import module java.base;`
import module java.xml;

void main() {
	// XML types are imported via java.xml
	var xml = DatatypeFactory.newDefaultInstance();
	// `List`, `BigDecimal`, `LocalDate`, etc. are imported via java.base
	List<?> dates = Stream
		.of(1, 2, 23, 29)
		.map(BigDecimal::new)
		.map(day -> LocalDate.of(
			2024,
			RandomGenerator.getDefault().nextInt(11) + 1,
			day.intValue()))
		.map(date -> xml.newXMLGregorianCalender(...))
		.toList();

	System.out.println(dates);
}

Embedded video.

Structured Concurrency and Scoped Values

The structured concurrency API lets you use virtual threads to write concurrent code that is easier to understand, maintain, and debug. And the scoped values API provides a more maintainable and scalable alternative to thread locals but is limited to values that won't change during a thread's life time. In JDK 23, both APIs are previewing for the third time - the only change is:

The type of the operation parameter of the ScopedValue.callWhere method is a now new functional interface which allows the Java compiler to infer whether a checked exception might be thrown. With this change, the ScopeValue.getWhere method is no longer needed and is removed.

private final static ScopedValue<Long> REQUEST_ID = ScopedValue.newInstance();

void main() throws Exception {
	var userOrder = ScopedValue.callWhere(REQUEST_ID, 42L, () -> fetchUserOrder("", ""));
	println(userOrder);
}

UserOrder fetchUserOrder(String userId, String orderId) throws InterruptedException {
	try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
		Subtask<User> user = scope.fork(() -> fetchUser(userId));
		Subtask<Order> order = scope.fork(() -> fetchOrder(orderId));

		scope.join().throwIfFailed();
		return new UserOrder(user.get(), order.get());
	} catch (ExecutionException ex) {
		var message = "Request %d failed".formatted(REQUEST_ID.get());
		throw new RuntimeException(message, ex.getCause());
	}
}

In fact, this is the only change since their first preview in JDK 21, so if you're on that version, you can still test the APIs in almost their current form. If you do and have any feedback, please send it to the Loom mailing list.

Embedded video.

Class-File API

Updating Java often requires updating many or even all of your dependencies and a big contributor to that undesired requirement is bytecode manipulation, a connection I explained in more detail in Inside Java Newscast #56. To minimize that effect, the JDK is currently previewing its own bytecode analysis and manipulation API: the class-file API. In its second preview, the CodeBuilder class was streamlined and the ClassSignature class was improved to more accurately model the generic signatures of superclasses and superinterfaces.

Embedded video.

Stream Gatherers

The stream API has a bunch of terminal operations like findAny, count, reduce, and since JDK 16, toList. One terminal operation isn't quite like the others, though, and that's collect. That's a generalized terminal operation that feeds stream elements into the provided collector, which we can code up freely to do pretty much whatever we want. This gives us the freedom to use all the collection strategies we need without the stream API having to support them all individually.

Now take all that and apply it to intermediate operations and you get Stream.gather and gatherers. This is a generalized intermediate operation that feeds stream elements into the provided gatherer, which can store them, apply some function to them, or pass anything on to the next stage of the stream pipeline. This gives us the freedom to implement all intermediate operations we ever wished, once again without the stream API having to support them all individually.

This API first previewed in JDK 22 and will do so again unchanged in JDK 23.

Embedded video.

Vector API

Big news for the vector API! No, it's not moving forward but in its eighth incubation the JEP now officially says why not. Quote:

The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them, and will promote the Vector API from incubation to preview.

There you have it, now we only need to wait for Valhalla to ship those features. Should be any day now. Brian.

The Novelty

That was quite a list but we're not done with JDK 23 yet: We still have the final features and some removals to cover.

But before we get to that I want to explain what the novelty of the JDK 23 branch is. And it's the thing itself: the branch. In the past, JDK releases each got a new fork - this decision was made way back when OpenJDK used Mercurial, which didn't support branches very well at the time. Nowadays OpenJDK uses Git, where branching is trivial, so the prerelease code of 23 and later versions will no longer get their own forks but merely branches.

Now let's get to the final features.

Final Features

ZGC Becomes Generational By Default

Let's start with ZGC, a garbage collector that prioritizes low pause times. It's been production-ready since JDK 15 but learned a new trick in JDK 21. Since then it has a generational mode that leans on the generational hypothesis and improves performance for most use cases, sometimes considerably. Companies like Netflix and Mercado Libre adopted it and are extremely happy with the results. If you want to learn more about all that, I recommend ZGC contributor Stefan Johansson's talk at Devoxx UK.

What's new in JDK 23 is that the generational mode is now the default. To avoid misunderstandings: G1 is the default garbage collector if you don't pick a different one. If you do pick ZGC with the flag -XX:+UseZGC, it will now be generational by default. You can opt out of the generational mode with -XX:-ZGenerational but not that much longer. While non-generational ZGC isn't deprecated yet, that's just a matter of time.

If you've never used ZGC, this is a good time to consider it. It works great for latency-sensitive applications like web backends and ideally you have a performance benchmark for your app that you can run with its current GC configuration versus with ZGC and compare the results. If they look promising, dig a bit deeper and maybe adopt.

Embedded video.

Markdown in Comments

If you've ever turned on subtitles on my videos, you might've noticed that they're written in Markdown. There are two reasons for this:

One is that I'm lazy. I write the script in Markdown because I'll later publish it on my blog and then I don't have to add all that inline markup later.
The other is that I think Markdown has become a kind of lingua franca among developers because it's supported in some form or other by almost every system we use to communicate by text: issues, pull requests, chat systems, Q&A sites, forums, and the list goes on and on. This has gone so far that I actually think that for most devs even reading source Markdown is easier than reading unmarked text because the markup helps with identifying code, emphasis, and structure.

So Markdown makes it easier for me to express and easier for you to understand what I want to communicate, even compared as-is to flat text! Now compare it to HTML and the gap just grows wider.

So I think it's really cool that JavaDoc now supports Markdown. If you start your block comment with three slashes and keep putting those before every new line, JavaDoc will interpret the whole text as Markdown, specifically CommonMark, and output the appropriate HTML. This will obviously help with writing documentation but also with reading it. I don't know about you but I usually read JavaDoc straight from the IDE, sometimes on GitHub, but not that often rendered on a website.

There's way more to say about all this - check out JEP 467 or Inside Java Newscast #68 for all the details.

Embedded video.

Deprecations

Last but not least we have two topics about things going away. In fact they're so "not least" that I will probably make a Newscast about each of them in the upcoming months - you know what to do if you don't want to miss that.

String Templates

The first thing going away is string templates. The short explanation is that after gathering practical experience with the feature and reevaluating how certain design goals can be achieved, the OpenJDK community felt that, as-is, string templates aren't pulling their weight. And because further evaluations and a potential redesign will take a little while, the preview was pulled entirely from JDK 23. That means, once you update your experimental and hobby code bases, you'll have to rip out everything related to string templating:

all strings with \{ in them
all mentions of STR and FMT
all references to the type StringTemplate and its inner class Processor

I'm very much not looking forward to that! The long explanation - well that's gonna be in the future Newscast.

Unsafe Memory Access

The other things going away are the memory-access methods on Unsafe but not yet in JDK 23. It only marks those methods as deprecated for removal. The plan is for JDK 25 to additionally issue warnings at run time when they're invoked and for future releases to first throw exceptions and eventually remove the methods. You can (and probably should!) simulate most of that on JDK 23 with the new command line flag --sun-misc-unsafe-memory-access, which you can set to warn or even deny to observe whether your app behaves as expected.

Removing these methods is part of a long-term plan to ensure the Java Platform has integrity by default. I touched on that topic when discussing JDK 21 because it was the reason why 21 started issuing a warning when an agent is dynamically attached. There's a timestamped link to that Newscast in the description or you can wait for the upcoming one that explores integrity by default as a whole: from dynamic agents to Unsafe, from modules to JNI and FFM.

Outro

And that was it for JDK 23. Later today, early access build number 26 will be released, so why don't you download it and take it for a spin? Keep in mind that for some of these features, you don't need to compile to JDK 23. You can compile to 21 and just run on 23 to see how generational ZGC behaves or whether you'll be impacted by the deprecations in Unsafe, for example.

The link to JDK 23 EA builds is in the description, right below the like and subscribe buttons and if you want to do me a favor, you can hit one or both of them while scrolling past. I'll see you again in two weeks. So long...

Watch the video.

Separate Operations From Data - Data-Oriented Programming v1.1

Nicolai Parlog — Wed, 05 Jun 2024 00:00:00 GMT

Data-oriented programming guides us towards a separation of data and operations. Operations should be implemented in dedicated subsystems, using pattern matching over sealed interfaces to pick execution branches and deconstructing records to implement domain logic.

Not surprisingly, data-oriented programming (DOP) has a strong focus on data. In fact, three of the four guiding principles of DOP v1.1, which we're exploring in this series, advise how to best model that. In this article, we'll examine the fourth principle, which concerns the methods that implement most of the domain logic. It advises to separate operations from data.

We'll continue to use the example of a simple sales platform that sells books, furniture, and electronic devices, each of which is modeled by a simple record. They all implement the sealed interface Item, which declares no methods because there are none that the three subclasses share.

Operations

When exploring how to model data, I laid out which methods fit well on records and which less so. I basically excluded all methods that contain non-trivial domain logic or interact with types that don't represent data - let's call them operations. Operations turn an extensive but ultimately lifeless data representation into a living system with moving parts.

In data-oriented programming, operations should not be defined on records but on other classes. Adding an item to the shopping cart would neither be Item.addToCart(Cart) nor Cart.add(Item) because Item and Cart are data and therefore immutable. Instead, the ordering system Orders should take over this task, for example with Orders.add(Cart, Item), which returns a new Cart instance that reflects the operation's outcome.

If other subsystems need the current shopping cart, they should have a reference to Orders instead of a reference to the mutating shopping cart and, if necessary, query the current shopping cart of a user via Orders.getCartFor(User). Communication between subsystems isn't implemented implicitlyby sharing mutable state, but rather explicitly through requests for the current state. State changes are still possible, but there are restrictions on where they should take place - ideally only in the subsystems that are responsible for the respective subdomain.

But how are these operations implemented? At first glance it seems quite difficult to do anything useful with an Item if the interface does not define any methods.

Pattern Matching

This is where pattern matching with switch comes into play. The switch statement has recently been improved in quite a few areas:

It can be used as an expression, for example to assign a value to a variable with var foo = switch ....
If a case label is followed by an arrow -> (instead of a colon :), there is no fall-through.
The selector expression (the variable or expression in parenthesis that follows the keyword switch; colloquially, what is being "switched over") can have any type.

It is the last point that is crucial here: If the selector expression does not have any of the originally permitted types (numbers, strings, enums), it is not matched against concrete values but against patterns - hence pattern matching. The value of the selector expression is compared to one pattern after another, top to bottom, until one matches. Then, the branch on the right side of the label is executed. (The actual implementation is optimized and works non-linearly.)

In their simplest form, patterns are type patterns like the one we've used when implementing equals. Processing an item, for example, looks as follows:

public ShipmentInfo ship(Item item) {
	return switch (item) {
		case Book book -> // use `book`
		case Furniture furniture -> // use `furniture`
		case ElectronicItem eItem -> // use `eItem`
	}
}

Here, the variable item is compared to the types on the left and if it is, for example, a piece of furniture, the type pattern case Furniture furniture matches. This declares a variable furniture of type Furniture and casts item into it before executing the associated branch, where furniture can then be used. On the right side of the arrow, the logic that matches the operation (here: shipping an item) and the specific data (here: an instance of Book, Furniture or ElectronicItem) can then be executed. And because data is modeled transparently, all information is available to the operation.

This ultimately implements dynamic dispatch: selecting which piece of code should be executed for a given type. If we would have defined the method ship on the interface Item and then called item.ship(...), the runtime would decide which of the implementations Book.ship(...), Furniture.ship(. ..) and ElectronicItem.ship(...) ends up being executed. With switch we do this manually, which allows us not to define the methods on the interface. We have already highlighted some of the reasons why this makes sense:

Records should not implement non-trivial domain logic but remain simple data.
Records should not execute operations but be processed by them.
Many operations are difficult to implement on immutable records.

Another important reason has emerged during the short discussion about object-oriented programming (OOP) in this series' first article: Types that model central domain concepts tend to attract too much functionality and therefore become difficult to maintain. DOP avoids this by placing the operations in the respective subsystems, i.e. Shipments.ship(Item) instead of Item.ship(Shipments) (where Shipments is the system responsible for deliveries).

The requirement to separate operations from the types they operate on is well-known in OOP, too. The Gang of Four has even documented a design pattern (no relation to pattern matching) called the visitor pattern that meets exactly this requirement. In this respect, DOP is in good company, but thanks to modern language features, it can use pattern matching, which is much simpler and more direct than the visitor pattern.

More detailed patterns

Type patterns in switch are essential for data-oriented programming. This may not apply to the five other types of patterns Java supports (or is about to), but they are certainly helpful, which is why we will briefly discuss them here. Each section includes a reference to the JDK Enhancement Proposal (JEP) that introduced the feature in detail.

Record Patterns

Record patterns were finalized in Java 21 by JEP 440 and allow a record to be deconstructed directly during matching:

switch(item) {
	case Book(String title, ISBN isbn, List<Author> authors) -> // use `title`, `isbn`, and `authors`
	// more cases...
}

You can alternatively use var, in which case the code in brackets would be var title, var isbn, var authors, or any mix of var and explicit types if you want to make your colleagues really angry.

Unnamed Patterns

Breaking down records is very convenient, but having to list all components every time is annoying when you only need some of them. This is where unnamed patterns come in, which were standardized by JEP 456 in Java 22. They allow replacing unnecessary patterns with the single underscore _:

switch(item) {
	case Book(_, ISBN isbn, _) -> // use `isbn`
	// more cases...
}

Unnamed patterns can also be used at the top level:

switch(item) {
	case Book book -> // use `book`
	case Furniture _ -> // no additional variable in scope
	// more cases...
}

We will see later, when we get to maintainability, why this is a crucial feature.

Nested Patterns

Since the finalization of patterns in switch in Java 21 by JEP 441, you can nest patterns inside each other with nested patterns. This allows us to dig deeper into a record, for example with two nested record patterns. Assuming that ISBN is also a record, it can look like this:

switch(item) {
	case Book(_, ISBN(String isbn), _) -> // use `isbn`
	// more cases...
}

Guarded Patterns

If the domain logic needs to distinguish not only by type but also by value, it might seem natural to simply use an if on the right side:

switch(item) {
	case Book(String title, _, _) -> {
		if (title.length() > 30)
			// handle long title
		else
			// handle regular title
	}
	// more cases...
}

Guarded patterns were also part of JEP 441 and they allow such conditions to be pushed to the left:

switch(item) {
	case Book(String title, _, _) when title.length() > 30 -> // handle long title
	case Book(String title, _, _) -> // handle regular title
	// more cases...
}

This has a few advantages:

All conditions, i.e. which type and which value is selected, are found on the left, improving the code's structure and readability.
If different components are required for different branches, the ones that are not required can be conveniently ignored.
Guarded patterns are integrated into the completeness check that we will discuss in the next section.

Primitive Patterns

Lastly, a quick word about primitive patterns, which were introduced by JEP 455 as a preview feature in Java 23. They allow switch statements over primitive types (i.e. "classic" switches) to be extended with patterns, which makes it easier to capture the value of a selector expression and allows it to be used in a guarded pattern:

switch (Rankings.of(book).currentRank()) {
	case 1 -> firstPlace(book);
	case 2 -> secondPlace(book);
	case 3 -> thirdPlace(book);
	case int n when n <= 10 -> topTenPlace(book, n);
	case int n when n <= 100 -> nthPlace(book, n);
	case int n -> unranked(book, n);
}

Maintainability

A switch that compares by type will certainly give more than a few OOP veterans goosebumps. Should a glorified instanceof check really be the basis for a whole programming paradigm?

This idea is worth pursuing. Why is instanceof frowned upon? (Given the medium, this question is obviously rhetoric, but I still recommend to take a minute to come up with an answer before reading on.) The answer consists of two parts:

Code that works with an interface should work for all its implementations.
When adding a new implementation, a series of instanceof checks is chronically difficult to update because it's hard to find.

In other words: Dynamic dispatch via instanceof checks is unreliable.

This is exactly why the visitor pattern has become widespread in object orientation: It also implements dynamic dispatch. (In case you lost count: After interface/implementation, switch with type patterns, and instanceof, this is now the fourth way to implement dynamic dispatch.) The visitor pattern does this in a way that is reliable, although somewhat cumbersome and sometimes difficult to understand because of its indirection. That's so because each new implementation of the visited interface generates a series of compile errors that can only be fixed by making every existing visitor (i.e. every operation) take the new type into account.

And here comes the crucial point: The same can apply to a switch with patterns!

Exhaustiveness

Such a switch must be exhaustive, meaning that for every possible instance that has the type of the selector expression, there must be a pattern that matches it or the compiler reports an error. There are three different ways to achieve this:

A default branch that catches all remaining instances at the end:

switch (item) {
	case Book book -> // ...
	case Furniture furniture -> // ...
	default -> // ...
}

A pattern that has the same type as the selector expression and thus has the same effect as default:

switch (item) {
	case Book book -> // ...
	case Furniture furniture -> // ...
	case Item i -> // ...
}

Listing all implementations of a sealed type:

switch (item) {
	case Book book -> // ...
	case Furniture furniture -> // ...
	case ElectronicItem eItem -> // ...
}

Unfortunately, the first two variants do not help us achieve our goal. Such a switch would still be exhaustive when adding a new implementation and would therefore not produce a compile error. So if posters were added to the web shop, they would silently end up in default (1.) or in case item (2.). In the third variant, however, there would be no branch for posters and so we'd get a compile error, which forces us to update the operation. Excellent.

In order for operations to be maintainable (meaning they cause compile errors if they do not explicitly cover all cases), there must be no default or catch-all branch, which is only possible when:

switching over a sealed interface (or sealed abstract class but we're ignoring those) and
listing all implementations

The last point also explains why sealed interfaces work better than sealed classes (remember that nugget from two articles ago?). If Item were a non-abstract class, a switch with Book, Furniture, and ElectronicItem branches would not be exhaustive because there could be instances of Item itself and there is no branch for them. If you process it with case Item, though, this branch would also handle every new item, such as a poster, and there would be no compile errors.

The last section's comment on completeness checks of guarded patterns should also make sense now.

switch(item) {
	case Book(String title, _, _) -> {
		if (title.length() > 30)
			// handle long title
	}
	// more cases for other types...
}

In this example, books with short titles would be ignored, which may be an oversight and probably not obvious in longer code. This wouldn't have happened with guarded patterns:

switch(item) {
	case Book(String title, _, _) when title.length() > 30 -> // handle long title
	case Book _ -> { /* ignore short titles */ }
	// more cases...
}

Here, after case Book ... when ..., there must be a branch for all books, which then either fixes the bug that books with short titles were forgotten, or (as shown) makes it explicit that they are intentionally ignored.

Avoiding Default Branches

Finally, a note on default branches and how to avoid them. It happens every now and then that a switch really only wants to handle some cases and ignore the others or treat them collectively in some other way - a default branch seems to be the obvious solution:

switch(item) {
	case Book book -> createTableOfContents(book);
	default -> { }
}

As discussed, however, this should be avoided at all costs and the addition of Magazine implements Item (which are not books but still require a table of contents) again highlights the problem. Instead, several case labels with unnamed patterns can be combined into one:

switch(item) {
	case Book book -> createTableOfContents(book);
	case Furniture _, ElectronicItem _ -> { }
}

This is a little more code than default ->, but produces the desired compile error when adding magazines and should therefore be preferred.

If you stick with Java 21 for the time being, you can only use unnamed patterns as a preview feature. Since it was finalized without changes in Java 22, this would be conceivable. But be aware that, when activating preview features with --enable-preview, all of them become available and you have to be careful not to use other, more volatile preview features (like string templates, for example 😬).

Summary

To keep data-modeling records free of non-trivial domain logic and prevent bloated APIs, operations should not be implemented on them but rather in dedicated subsystems. Operations will then often process sealed interfaces that usually offer very few methods to interact with. Instead, they will switch over those interfaces and enumerate all implementations, thus implementing their own dynamic dispatch. As long as default and catch-all branches are avoided, this is future-proof because new interface implementations will make these switches non-exhaustive. This causes compile errors that lead developers directly to the operations that need to be updated for the new type.

Learn more about version 1.1 of data-oriented programming in this article series:

Data-Oriented Programming in Java - Version 1.1
Model data immutably and transparently - DOP v1.1
Model the data, the whole data, and nothing but the data - DOP v1.1
Make illegal states unrepresentable - DOP v1.1
Separate operations from data - DOP v1.1 (this article)
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1?

Make Illegal States Unrepresentable - Data-Oriented Programming v1.1

Nicolai Parlog — Mon, 03 Jun 2024 00:00:00 GMT

Data-oriented programming focuses on modeling data as closely as possible and a guiding principle for achieving that is to ensure that the software can not represent illegal states. That can be achieved with good type design or with constructor checks (plus tests).

A system focused on data should ensure that only legal combinations of the data can be represented in the system and so a guiding principle of data-oriented programming is to make illegal states unrepresentable. We'll examine that in this article, the fourth in a series that refines the four DOP principles in a version 1.1.

Make Only Legal States Representable

The world is chaotic and every rule seems to have an exception. "Every user has an email address" quickly becomes "every registered user has an email address, but it may be missing during the registration process." When modeling that, you might get stuck with a User who has a String email field that can be null (or otherwise absent, e.g. with Optional) at any time, and the fact that registered users must have an email address is implicit at best but no longer enforced.

With such a design, you're not doing yourself any favors! In any system, but especially in one with a data-focused design, you'll benefit from only making legal states representable.

If a User needs to have an email address, the constructor should ensure that this is the case. If no product can have both an ISBN and battery life, this must be prevented - ideally by modeling the data so precisely that there is no type that has both fields (see the previous article for details on that). Precise types like that not only have the advantage that their creator doesn't have to write constructors and tests that verify that illegal combinations don't occur, but also help the developers using them. When they see an Item, they don't have to ask themselves whether they can call isbn() or dimensions() because Item has none of these methods - Book has one and Furniture has the other.

So the plan is:

Use precisely modeled types (usually records) to describe the data.
In either/or situations, avoid multiple fields with mutually exclusive or conditional requirements and instead create a sealed interface to model the alternatives and use it as the type for a mandatory field.
Only if these design techniques, both of which are supported by the compiler, are not sufficient, resort to run-time checks in the constructor.

Validate at the Boundary

When a property of the data can't be expressed so that the compiler enforces it, it must be validated at run time. But not just any time, it should generally happen as early as possible, ideally right at the boundary between the external world and your system - whether that means when the file is read from disk, when the database replies to a query, or when another app sends some JSON.

Validating the data this early ensures that no broken data enters the system but it is also important to make sure that the system doesn't generate broken data. That means the instances it creates that may later be mapped back to CSV, JSON, an SQL query, etc. must also be validated. That makes the constructors of these types the ideal place for validation logic. In more complicated cases, factory methods or classes may be involved, in which case they need to apply these checks of course.

Here are a few examples of such validation logic, placed in a compact constructor for brevity:

record Book(String title, ISBN isbn, List<Author> authors) {

	Book {
		Objects.requireNonNull(title);
		if (title.isBlank())
			throw new IllegalArgumentException("Title must not be blank");
		Objects.requireNonNull(isbn);
		Objects.requireNonNull(authors);
		if (authors.isEmpty())
			throw new IllegalArgumentException("There must be at least one author");

		// plus immutable copies as in the previous article
	}

}

Modeling Variants

So, how do you deal with users who don't have an email address until they suddenly do?

sealed interface User permits UnregisteredUser, RegisteredUser { }
record UnregisteredUser(/*...*/) { }
record RegisteredUser(/*...*/, Email email) {
	// constructor enforces presence of `email`
}

Then the email verification system takes an UnregisteredUser and an Email, the overall registration process accepts an UnregisteredUser and returns a RegisteredUser, the newsletter dispatch only accepts RegisteredUser, and any API that can handle both uses User for their parameters. This not only keeps the user types precise, it also allows the respective subsystems to clearly express which users they can handle.

And with that we can finally get to exactly these subsystems and how they process data - in the next article.

Summary

Most systems, especially ones with a data-focused design, will benefit from only making legal states representable. To achieve that in data-oriented programming, start by modeling data closely and don't shy away from creating several types for different variations of "the same data" (can't quite be the same if it has variations). In those situations or any other were different data is related, use sealed interfaces to model such alternatives. Every property of the data that can't be captured by types should be validated during construction.

Learn more about version 1.1 of data-oriented programming in this article series:

Data-Oriented Programming in Java - Version 1.1
Model data immutably and transparently - DOP v1.1
Model the data, the whole data, and nothing but the data - DOP v1.1
Make illegal states unrepresentable - DOP v1.1 (this article)
Separate operations from data - DOP v1.1
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1?

Model Data, the Whole Data, and Nothing but the Data - Data-Oriented Programming v1.1

Nicolai Parlog — Wed, 29 May 2024 00:00:00 GMT

Data-oriented programming (DOP) centers around modeling data as closely as possible and so a core principle of DOP is to 'model the data, the whole data, and nothing but the data'. This goal is best achieved with a mix of records and sealed types as well as some programming practices that may seem odd to the object-oriented developer - all of which is explored in this article.

It should come as no surprise that data-oriented programming (DOP) centers around modeling data as closely as possible and so a core principle of DOP is to model the data, the whole data, and nothing but the data. This goal is best achieved with a mix of records and sealed types as well as some programming practices that may seem odd to the object-oriented developer.

We'll explore all that in this article, the third in a series that refines the four DOP principles in a version 1.1. After the previous article discussed how to model data immutably and transparently with records, we can now focus on sealed types and the aforementioned programming practices. We'll continue to use the example of a simple sales platform that sells books, furniture, and electronic devices, which are each modeled by a simple record.

Sealed Types

Once we have created the records Book, Furniture, and ElectronicItem, the central domain data is modeled. Not completely, though, because there exists a relationship between them that has not yet been captured: Every item in our shop is either a Book, a (piece of) Furniture, or an ElectronicItem. To represent that relationship, we use sealed types.

Sealed types have been finalized in Java 17. A class or an interface is marked as sealed by the keyword sealed and then only the types listed in the permits clause can inherit from it - other types are forbidden to do so under penalty of compilation error. This mechanism is perfect for modeling alternatives. The sentence "an item is either a book, a piece of furniture, or an electronic device" becomes:

sealed interface Item permits Book, Furniture, ElectronicItem {
	// ...
}

Sealed types are particularly useful when the system cannot be expected to simply work when a new implementation is added. Another List implementation? No problem, this will work seamlessly. Another Item implementation? Now VAT rates have to be checked, dedicated views such as the apartment planner or the display of the table of contents have to be adjusted and maybe new delivery methods have to be introduced.

There are many other situations where just adding an interface implementation isn't going to work. Authentication providers or payment methods, for example: It doesn't suffice to just code up CreditCardPayment implements Payment because at least the associated payment system must also be implemented plus probably a mechanic that collects the payment in the right place in the code and ferries it to the suitable payment system. We'll see how this works elegantly with sealed types in the article on operations.

First, a few properties of sealed types:

Allowed subtypes must be in the same module or (if the code is not compiled as a module) in the same package as the sealed type.
If the sealed type and permitted subtypes are contained in the same source code file, the permits clause can be omitted.
Allowed subtypes must inherit directly from the sealed type.
Allowed subtypes must be final, sealed or explicitly non-sealed (Java's first hyphenated keyword!).

While it is certainly possible and sometimes useful to seal classes, dealing with sealed interfaces is much more pleasant in one very specific aspect, which we'll get to when we discuss operations. That is why I generally recommend focusing on sealed interfaces and so this article series is doing that as well.

Model Nothing but the Data

Records make it easy to aggregate data, while sealed types make it easy to express alternatives. In combination, these two mechanisms are very powerful and allow even complicated structures to be modelled well.

Tailored Aggregates and Alternatives

The easy definition of records invites us to create tailor-made and possibly numerous types. Instead of User getting components for street, ZIP code, city, and country, these are probably better stored in an Address record, of which the user then has an instance.

And if the address is optional and a user can also optionally store an email address and a telephone number, instead of having a possibly-absent field for each contact information, you can give the type a List<ContactInfo> contacts field with sealed interface ContactInfo permits Address, Email, Phone. Is at least one contact information required? Have a ContactInfo primaryContact field and rename the list to additionalContacts.

The goal is to use these features to tailor the types to the actual domain data. This makes the code easier to understand for developers as it closely resembles the data they need to know anyway and it also makes it easier to maintain because illegal data is more easily rejected - more on that when we examine how to represent only legal states.

Equality (and Type Patterns)

A central part of modeling data is the definition of equality. As described in the article on records, they come with an equals (and hashCode) implementation that uses all components. This is fine in many cases, but especially in systems that work with users and items, IDs are ubiquitous and most objects that have one should probably use it to determine equality. That's one of many reasons why it's common to override equals (and hashCode).

In our example, it makes sense to define the equality of Book based on the ISBN. We can do this very elegantly with the help of a feature that will become much more important later: type patterns, standardized in Java 16, in this case with instanceof.

record Book(String title, ISBN isbn, List<Author> authors) {

	@Override
	public boolean equals (Object other) {
		return this == other
			|| other instanceof Book book
			&& Objects.equals(isbn, book.isbn);
	}

	@Override
	public int hashCode() {
		return Objects.hash(isbn);
	}

}

The type pattern is found in other instanceof Book book. It accomplishes three tasks:

checks whether other is an instance of type Book
defines a new variable Book book that is visible ("in scope") wherever the test returns true
assigns book = (Book) other

Since the book variable is visible exactly where the type check was positive, you can use it directly after the && to compare the desired fields.

(Note: Implementing equals with instanceof is not always correct, but no problem here because Book is final.)

Methods

You can implement arbitrary methods on records, but as transparent carriers of data, they prefer some methods over others:

Methods without parameters are best because they can't do anything other than return the record's data (unless they reference global variables, which is extremely rarely a good idea). For example, email.tld() could identify and return the top level domain of the email address or book.byline() could combine the book title and authors into a string.
Methods that accept the type itself as the only parameter are also welcome. For example, this could be compareTo if you implement Comparable, or Book could have a method commonAuthors(Book) that returns a list of authors who were involved in both books.
Methods that accept other records (preferably those that are already used as a component type) are usually OK as well: Because they're also supposed to be immutable data carriers, it can be assumed that no states are changed and all results are communicated via the return value. However, in this situation it becomes important to avoid implementing non-trivial domain logic. According to the principle separate operations from data, such operations should be reserved for external systems.
Methods with arbitrary parameters, particularly mutable ones, have a high chance of turning the record from data that is being processed as part of an operation into the executor of these operations, which should generally be avoided.

Note that these aren't hard-and-fast rules but rather guidelines that can be suspended if the situation demands it, but then you should have a good reason for doing so.

Interface Contracts

If, in data-oriented programming, records mostly just offer access to data with little to no additional operations, you may ask yourself how to use interfaces in such a design - after all, we mostly employ them to model contracts for behavior. And indeed, this role is much less important here. (Sealed) interfaces implemented by records do not primarily define what a type does but rather what it is:

Books, electronic devices, and furniture are items.
Addresses, emails, and telephone numbers are contact information.

As can be seen in these examples, the types united under an interface often have very little overlap. While items probably at least all have an item number, the different contact information are entirely distinct. Accordingly, interfaces like ContactInformation may end up without a single method. This is unusual and "looks wrong", but that's just a matter of familiarity. The contract that is defined here does not describe behavior (which is no meaningful category for data) but grouping (which data are alternatives to each other in the context of the interface) and no methods are needed for that.

Summary

Use records to aggregate data into meaningful, tailored types and sealed interfaces to express alternatives between such types. Because data doesn't come with behavior, such records usually declare few or no methods that don't just return the data in a different form. Consequently, the sealed interfaces they implement may declare few or no methods, which can be novel but is expected as the contract they describe is about what the data is (not what it does).

Learn more about version 1.1 of data-oriented programming in this article series:

Data-Oriented Programming in Java - Version 1.1
Model data immutably and transparently - DOP v1.1
Model the data, the whole data, and nothing but the data - DOP v1.1 (this article)
Make illegal states unrepresentable - DOP v1.1
Separate operations from data - DOP v1.1
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1?

Model Data Immutably and Transparently - Data-Oriented Programming v1.1

Nicolai Parlog — Mon, 27 May 2024 00:00:00 GMT

To model data immutably and transparently is one of the four principles of data-oriented programming. In this article, we explore why immutability and transparency are important when modeling data and how to use Java's features, particularly records, to achieve that.

To model data immutably and transparently is one of the four principles of data-oriented programming. In this article, the second in a series that refines these principles in a version 1.1, we explore why immutability and transparency are important when modeling data and how to use Java's features, particularly records, to achieve that.

Immutability and Transparency

A common source of software errors is the proliferation of objects that are modified by different subsystems. It happens again and again that code at one end of the code base changes an instance without code at the other end noticing this even though it needs to react to it.

A particularly simple and drastic example is storing an object in a HashSet and later changing a value that is used in the hash code calculation. The HashSet does not notice this change, can't re-enter the object under its new hash code, and as a result, it is suddenly undiscoverable.

In this example, two subsystems (the HashSet and the code that modifies the object) have access to the same object, but have different requirements for modifying it and no way to communicate them - developers have to know them. Here, this is often the case and most Java developers know that computing hash codes from mutable fields is problematic, but that is only the case because one of the two affected systems is a well-known one with a simple contract ("don't do it") - in more complex and self-built systems this is much more difficult to keep track of.

The simplest approach that guarantees correctness is immutability: If nothing can change, such errors cannot occur. And if subsystems only communicate with immutable data, then this common source of errors entirely disappears.

But if the data cannot change, the necessary state changes must take place in the systems that process it. And just as a mutable object can take its entire state into account before changing it, these systems now have to take the entire state of the processed objects into account (more on this in the article on operations) and for that the objects must be transparent. An object is transparent if its internal state is accessible and constructable via the API, i.e.:

There must be an access method for each field that returns the same (==) or at least an equal (equals) value.
There must be a constructor that accepts a value for all fields and, if they are in the valid range, saves them directly or at least as a copy.

Taken together, this means that given an existing instance you can create a new one that is indistinguishable from the first apart from its identity (==) by querying all fields and calling the appropriate constructor.

Records

So we want to work with transparent carriers of immutable data. And as luck would have it, records were designed just so! Finalized in Java 16, records describe data as part of their type definition by declaring so-called components, each of which specifies a type and a name. If, for example, we want to model the data of a book with title, ISBN, and authors, the natural way to do that is as follows:

record Book(String title, ISBN isbn, List<Author> authors) { }

To function as transparent data carriers, a number of requirements must be met:

There must be a field for each component that stores its value.
These fields must be final ("immutable data").
There must be a canonical constructor that accepts and assigns exactly these values, as well as accessor methods that return them (transparency in construction and access).
The type must be final (otherwise the record's components would not fully describe the data).
The equals and hashCode methods are based on this data and not on the identity of the record instance ("carrier of data").

Instead of leaving it to us to fulfill these requirements, Java takes care of that and generates all these things. (This then is the reduction in boilerplate that we enjoy when using records, but it is important to understand that this is not their purpose but a welcome side effect of their actual purpose: to be transparent carriers of immutable data.)

That's why you can define simple records in a single line, although we'll soon see that, in practice, adjustments are very common. And those are entirely possible:

The canonical constructor, accessor methods, equals and hashCode can be overridden and thus customized.
It is possible to add more constructors and arbitrary methods (but not fields or "private components" as this contradicts transparency).
Records can implement interfaces.

Before we continue, I want to point out that records simplify data-oriented programming but are neither required nor enforced by it. For example, if one of their limitations prevents their use for a particular type, you can design it as a normal class as long as you still adhere to the DOP principles. In the context of this principle, this means designing the class so that it is immutable and transparent.

Immutability in Depth

Record fields are final, but that doesn't magically apply to what they reference:

record Book(String title, ISBN isbn, List<Author> authors) { }

// elsewhere
var threeBP = new Book(
	"The Three-Body Problem",
	new ISBN("978-0765382030"),
	new ArrayList<>());
threeBP
	.authors()
	.add(new Author("Liu Cixin"));

In this example, the list of authors could be changed after construction! To prevent that, records should, if possible, create immutable copies of mutable data structures in their constructors. The copyOf methods of List, Set and Map are suitable for Java collections:

record Book(String title, ISBN isbn, List<Author> authors) {

	Book {
		authors = List.copyOf(authors);
	}

}

Here I used a compact constructor, which does not require an explicit parameter list or assignments to fields. The parameters of a compact constructor are precisely the components of the record and after the code block is executed, the values are automatically assigned to the fields. So the constructor has to contain only what is absolutely necessary - here the copy of the author list by calling List.copyOf. And since the resulting list is immutable, calling authors().add(...) as above would result in an exception.

This can be more complicated for other data structures, especially your own. If there is no way to create immutable copies, you can make sure that nobody has a reference to the record's inner state by creating a copy in the constructor and then another copy in the overwritten access method:

// assume `ISBN` is a mutable class that has a copy constructor
record Book(String title, ISBN isbn, List<Author> authors) {

	Book {
		authors = List.copyOf(authors);
		// create a copy, so references to
		// the `isbn` argument can't change
		// the record's internal state
		isbn = new ISBN(isbn);
	}

	@Override
	public ISBN isbn() {
		// don't expose mutable inner state
		return new ISBN(isbn);
	}

}

Although this can be unexpected and also lead to bugs, it is typically less problematic than changing the record state itself.

If there is no technical solution, perhaps a communicative one will help: A team can agree to treat everything they get from a record as immutable and not to call methods that change the data structure.

Summary

A reliable way to reduce bugs in a code base is to limit the reach of potentially troublesome actions and at the top of that list is the mutation of state that is shared across multiple subsystems. Data-oriented programming proposes that subsystems communicate via data that is modelled immutably and transparently. Java makes this particularly easy with records, although a little care needs to be taken when records reference mutable data structures.

Learn more about version 1.1 of data-oriented programming in this article series:

Data-Oriented Programming in Java - Version 1.1
Model data immutably and transparently - DOP v1.1 (this article)
Model the data, the whole data, and nothing but the data - DOP v1.1
Make illegal states unrepresentable - DOP v1.1
Separate operations from data - DOP v1.1
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1?

Data-Oriented Programming in Java - Version 1.1

Nicolai Parlog — Thu, 23 May 2024 00:00:00 GMT

Many of the language features recently added to Java come together to support data-oriented programming - a programming paradigm first described for Java in June 2022 by Brian Goetz. This here is a proposal for a revised version 1.1.

In recent years, Java received a number of new language features that can be used independently of one another and that are each useful on their own: type patterns, switch improvements, records and record patterns, sealed types and a few other patterns. But as is occasionally the case, the whole is significantly more than the sum of its parts here and when correctly combined, these features can significantly impact our day-to-day coding. They invite us to fundamentally expand our repertoire of design patterns - in a well-known direction, but with a new twist. So in this series of six articles (see a detailed list at the end of this one), we will explore this style of programming and provide a minor update to the guidelines that Brian Goetz proposed for it in June 2022.

Object-Oriented Programming

Everything is an object.

Object-oriented programming (OOP for short) can be boiled down to this one sentence. It expresses that everything can or (in OOP) should be modeled as a combination of state and behavior. The most direct way to implement it is to create classes that combine mutable state with the methods that operate on them. These classes usually encapsulate their state and often inherit the contract for their methods from interfaces that represent the common features of different classes in one type.

In Java, this approach is ubiquitous and perhaps nowhere more obvious than in the collection API. From Iterable to Collection and List, from Queue to Set and more recently SequencedCollection and SequencedSet, interfaces define contracts, while concrete classes such as ArrayList or LinkedList, HashSet or TreeSet, PriorityQueue or ArrayDeque implement them in a variety of ways, always ensuring that their mutable state remains hidden so that outsiders cannot corrupt it.

It's no surprise, then, that we often design our own systems in a similar way. In a web shop, an item might be modeled by the Item interface, which is implemented by concrete classes such as Book (with an ISBN), Furniture (with dimensions) and ElectronicItem (with additional information about connections and battery power). The interface has methods like addToCart, purchase, ship, or reorder and new item types can be easily added to the system by implementing new classes.

But… it's often not that simple. While gathering all of these methods on Item seemed reasonable because they all interact with the purchasing process, adding predictLowStock (interacts with the machine learning-based pre-order system), registerForRecommendations (another ML system, this time for item suggestions) and reportPurchase (registration of the purchase of potentially dangerous goods) makes us doubt whether all of these operations really belong to the same interface. It's also problematic that tables of contents can only be displayed for books while the 3D apartment planner can only deal with furniture - should Item now get the methods tableOfContent and addToVirtualApartment, each of which contains meaningful behavior in only one out of three Item implementations with the other two throwing exceptions or doing nothing at all? Alternatively we could introduce flags or do instanceof checks, but that doesn't solve another problem that arises after some time: All of these subsystems share the item instances and repeatedly step on each other's toes when changing their state, which causes some unpleasant bugs.

Somehow it feels like our beautiful design is shattered by ugly reality. A key contributing factor is that OOP is best at modelling evolving processes like shipping time, inventory management, or recommendation systems but not that suitable for modeling the things these processes are operating on - like the items above. So, what can we do?

Data-Oriented Programming

Where object-orientation sees the world as a network of interacting objects, each with an internal, usually mutable state (perhaps similar to a natural ecosystem), data-oriented programming (DOP for short) sees it as a chain of systems, each with a potentially changing state, that operate on immutable data (comparable to a production line). Operations on immutable data? That sounds like functional programming (FP for short) and in fact DOP has a lot in common with it. But DOP also contains potentially-mutable systems that can be modeled in an object-oriented fashion. We'll talk a little about the relation between DOP, FP, and OOP in the last article in this series.

Data-oriented programming is based on a number of principles whose exact formulation isn't quite finalized. In his seminal article "Data-Oriented Programming in Java", Brian Goetz, Java Language Architect at Oracle, wrote in June 2022 (slightly reordered):

Data is immutable.
Model the data, the whole data, and nothing but the data.
Make illegal states unrepresentable.
Validate at the boundary.

That was version 1.0, so to speak. After using DOP for about 18 months in various projects (mostly demos and hobby projects, but one is also in production), I propose a first revised version 1.1 here:

Model data immutably and transparently.
Model the data, the whole data, and nothing but the data.
Make illegal states unrepresentable.
Separate operations from data.

Article Series

Over the coming weeks, we will publish an article on each of these four principles and close the series out with a sixth one that puts data-oriented programming in context of object-oriented as well as functional programming and gives some guidelines as to when and where to use it.

Data-Oriented Programming in Java - Version 1.1 (this article)
Model data immutably and transparently - DOP v1.1
Model the data, the whole data, and nothing but the data - DOP v1.1
Make illegal states unrepresentable - DOP v1.1
Separate operations from data - DOP v1.1
Wrapping up DOP v1.1
Bonus: Why Update DOP to Version 1.1?

Module Imports in Java 23 - Inside Java Newscast #69

Nicolai Parlog — Thu, 16 May 2024 00:00:00 GMT

To reduce the overhead of using APIs, particularly in single source files, Java 23 previews module import declarations of the form import module $moduleName, which import all packages exported by the named module

I wrote this book (The Java Module System) seven years ago and you know what? It's still up to date! Except for the planned tightening of screws on strong encapsulation from Java 9 to 16, the module system didn't change. Until now, that is, because Java 23 will preview a nifty little feature that builds on modules and - hey, hey, hey; don't leave - you can use it even if your code isn't in modules. Curious?

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about JDK Enhancement Proposal 476: module import declarations. This is a preview feature that was already merged into JDK 23, so you can try it in an early access build today. Although, I did find a bug in EA build number 22, so maybe wait for this week's 23 or next week's 24.

Anyway... ready? Then let's dive right in!

Star Imports

I'm a big proponent of single-type imports because of the clarity it affords, particularly when reviewing diffs. If you need List and Map, add import java.util.List and import java.util.Map. import java.util.*? All classes from some random package that's probably half an API? That way lies madness! It's anarchy! What's wrong with you, why do you want to see the world burn?!

But then I started writing single-source-file programs for experiments or short scripts, often outside of an IDE, and as the wind goes, so do I and I immediately and spinelessly started using star imports in those situations to make my life easier. Fast forward a few years, and in comes JEP 476, promising mass-imports on steroids. But they're not just more powerful, they're also quite a bit smarter.

Module Imports

JEP 476 previews so-called module import declarations of the form import module $moduleName;, which you can strew about your regular import statements. import module, say, java.sql imports all public top-level types in the packages exported by the module java.sql. It actually does a bit more than that but we'll get to that later.

This is at once more powerful than star imports because it can import a lot of packages (import module java.base, for example, imports 54) and it's smarter because a module usually exports a cohesive API, although java.base is not a good example for that. So if you import a module, you can be sure to have all types you need to use its API, whereas if you star-import a package, it regularly turns out that you need another package to make the API work.

So as I said, I only use star imports when prototyping or experimenting and I will definitely switch to module imports there. On that topic, the proposal for a simplified main method and class was updated for 23 (more on that in a future video) to not only allow module imports, but to automatically import java.base if the main class isn't explicitly defined. That means if you just have a main method in the file, you need no imports to use all of java.util, java.math, java.time, etc.

// complete Main.java; uses
//   * java.math.BigDecimal
//   * java.time.LocalDate
//   * java.util.List
//   * java.util.random.RandomGen…
//   * java.util.stream.Stream
// without explicit imports!
void main() {
	List<?> dates = Stream
		.of(1, 2, 23, 29)
		.map(BigDecimal::new)
		.map(day -> LocalDate.of(
			2024,
			RandomGenerator.getDefault().nextInt(11) + 1,
			day.intValue()))
		.toList();

	System.out.println(dates);
}

And if you want to experiment with, say, XML, just add import module java.xml - I love it!

// complete Main.java
import module java.xml;

void main() {
	var xml = DatatypeFactory.newDefaultInstance();
	List<?> dates = Stream
		.of(1, 2, 23, 29)
		.map(BigDecimal::new)
		.map(day -> LocalDate.of(
			2024,
			RandomGenerator.getDefault().nextInt(11) + 1,
			day.intValue()))
		.map(d -> xml.newXMLGregorianCalendarDate(...))
		.toList();

	System.out.println(dates);
}

But what about module imports in production code? I guess I'd switch to that if I'd already use star imports in such code. I don't see why not. If you use star-imports, I wanna know what you think you'll do - let me know in the comments.

Module Import Details

Let's talk about a few details in the proposal. First, as I mentioned in the intro, your code does not have to be in a module to be able to use module imports. If it is in a module, though, the import may actually import more classes: Say your module bar requires and module-imports the module beer. Then you not only import all packages beer exports in general but also all packages it exports explicitly to your module bar with a qualified export if there are any.

And regardless of whether your code is in a module or not, another round of packages may be imported if beer implies readability of malt with a requires transitive clause, namely malt's exported packages and this keeps going with more requires transitives. That may sound like a confusing jumble of extra rules but if you know the module system basics, it's quite simple: import module beer will import all packages that are exported to you via beer, which includes implied readability and qualified exports. And if you don't know the module system basics, well, then I got a bri... sorry, a book to sell you. And also some links in the description.

Importing that many packages can easily lead to ambiguities, though. Is List a reference to java.util.List or java.awt.List, is Date a reference to java.util.Date or java.sql.Date?

import module java.desktop;
import module java.sql;

void main() {
	// error: reference to Date is ambiguous
	var outdated = new Date(1997, 1, 18);

	// error: reference to List is ambiguous
	var letters = List.of("I", "J", "N");
}

To clarify such cases you can add a specific import for the respective type to your list of imports.

import module java.desktop;
import module java.sql;

import java.util.Date;
import java.util.List;

void main() {
	// error: friends don't let friends use Date!
	var outdated = new Date(1997, 1, 18);
	var letters = List.of("I", "J", "N");
}

More Modules?

When I said I wrote that book 7 years ago? That was a bit shocking - modules are that old already, huh? And me, too. Wow. Even I have to admit that adoption isn't great, but maybe this feature helps? Module imports surely are an additional incentive for libraries and frameworks to ship modules to make their users' lives easier. Let me know what you think. And while you're down there, check out the links in the description, leave a like, subscribe to the channel if you haven't already, and I see you again in two weeks. So long ...

Watch the video.

Java Withers - Inside Java Newscast #67

Nicolai Parlog — Thu, 18 Apr 2024 00:00:00 GMT

JEP 468 proposes a solution to the verbosity that can come from modeling mutable state with immutable records: derived record creation aka with expressions aka withers.

Java withers, Java ages, Java decays - that was the conception I wanted to play off of when picking this episode's title, but... I can't pull this off. I mean, I'm recording this video on the world's longest permanent race track and I'm here because of Java! Specifically, JavaLand, one of the very best Java conferences in a community flush with excellent events. The whole "Java is dying" schtick is lame anyway, but it's outright ridiculous to perform it here, so lets see whether we can't find another topic that fits the title "Java withers".

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about JDK Enhancement Proposal 468: Derived Record Creation, better known as "with expressions" or just "withers" - ha, that was easy! JEP 468 proposes an elegant solution to the verbosity that managing state with immutable records can cause in everyday programming. It became a candidate JEP earlier this year, which means it's ready to be targeted to a specific release. From what I can tell that may very well be JDK 23, but as Mike "String Template" Tyson once said: "Everybody has a plan until they get punched in the face", so, you know, let's not get ahead of ourselves.

Ready? Then let's dive right in!

When Immutability Births Verbosity

If you're on Java 17 or newer, I'm sure you've used records, probably a lot. They work great to model immutable data carriers and their transparency makes them very convenient: Free constructors, free accessors, free equals and hashCode, but many degrees of freedom - what's not to like?

record Point(int x, int y) { }

Well, there is one thing actually. Immutability is great - until you need to change something. Clearly you can't mutate a record's state and so they don't have "set" methods, commonly referred to as "setters".

var point = new Point(23, 42);
// we need a point with x = 0...

// records are immutable, so this
// won't work (fortunately!)
point.setX(0);

So the next best thing it so create a slightly changed copy. You can do that on the use site and just create a new instance of the record where all values except the one you want to change come from the old record.

var zeroX = new Point(0, point.y());

But that gets real old, really fast. To fix that you can move that code into the record itself: Create one method for each component that takes a new value for it and returns an appropriately copied instance. These methods usually start with the word "with" and are hence often called "withers".

// record definition
record Point(int x, int y) {

	Point withX(int x) {
		return new Point(x, this.y);
	}

}

var point = new Point(23, 42);
// call `withX` to get the copy
var zeroX = point.withX(0);

This is a solid approach and it works well, but it's a bit sad that while the language understands how to construct and deconstruct a record, it doesn't combine those capabilities and instead you have to manually drag data out of one and into the next instance. It also means that we once again end up with boilerplate code that not only needs to be written (or more likely generated) but also to be read again and again to make sure neither customizations nor errors are hiding in there.

Another shortcoming of this approach is that individual withers will fail you when you have constraints that span several components. Have a point that needs coordinates to be either all positive or all negative? Then you can't go from one state to the other via individual with... calls without the constructor throwing an exception in between.

record Point(int x, int y) {

	Point {
		var sameSign = x < 0 == y < 0;
		if (!sameSign)
			throw new IllArgException();
	}

	// ... `withX` and `withY`

}

var point = new Point(23, 42);
var mirroredPoint = point
	.withX(-p.x()) // 💥💥💥
	.withX(-p.y());

Then you either abandon withers entirely or create compound withers, which offer even more room for bugs to hide in. So, yeah, manual withers work but they're not great. And if Java wants us to use records everywhere they belong, it would be nice if it made those copies easier. And that's where JEP 468 comes in.

Derived Record Creation

JEP 468 proposes to derive new record instances from existing ones with the new with expression: A with expression starts with the so-called origin expression, which must be of a record type - in most cases this will be just a reference to a record variable. It's followed by the situational keyword with and ends with a transformation block - a pair of curly braces that can contain almost arbitrary code. The type of the whole expression is that of the origin expression, so you can, for example, assign it to a variable of the same type as the initial record variable.

So for a record Point(int x, int y) that could be Point updated = old with { x = 0; };:

Point old = new Point(23, 42);

//       origin expression
//               |
//               | (here of type `Point`)
//               ↓
Point updated = old with { x = 0; };
//                       ↑        ↑
//                     transformation
//                         block

At run time, Java will evaluate the origin expression to the so-called origin value. It will then take that record and create a variable for each component with the same type, name, and value (as given by the accessor), and make these local component variables available in the transformation block. It will then run the block, whose chief job it is to reassign some or even all of them. Technically, we can execute almost arbitrary code but we should really stick to succinctly computing and assigning new values - it's ok if that takes some control structures or method calls, but we really shouldn't include any logic here that isn't strictly necessary to achieve the goal. Once the block ran its course, the canonical constructor of the record type will be called with the local component values, thus giving you a new record instance that is like the old except for the components for which you just computed new values. Calling the constructor also ensures that all constraints are checked - you cannot create any illegal record instances this way.

// run-time pseudo-code for:
// Point updated = old with { x = 0; };

Point originValue = old;

// local component variables
int x = originValue.x();
int y = originValue.y();

// run transformation block
x = 0;

// create new instance
Point updated = new Point(x, y);

So for the record Point(int x, int y) and the statement Point updated = old with { x = 0; };, updated's x coordinate is 0 and its y coordinate is whatever old had.

Nitty Gritty

I said "almost arbitrary code" twice now. The most important limitation is that control flow cannot be passed outside the block with a return, yield, break, or continue. The block must either complete normally or throw an exception.

It's really cool that the block only needs to contain the minimum amount of code necessary to change the state between the two records. All unchanged state flows through it without being mentioned and so a small transformation is small. This minimalism mirrors that of compact record constructors, which also alleviate us of boilerplate, in this case assigning values to fields, and also focus on what's relevant, in this case the values that need to be checked, where else other data just flows through them without being mentioned.

record Point5D(int x, int y, int z, int a, int b) {

	Point5D {
		if (a < b)
			throw new IllArgException();
		// x, y, z silently flow
		// from parameters to fields
	}

}

var point = new Point(23, 42, 90, 2, 5);
var zeroA = point with {
	a = 0;
	// x, y, z, b silently flow
	// from `point` to `zeroA`
};

I thought that was a pretty witty observation. A shame half of you zoned out and instead of listening to me having an original thought for once were wondering what would happen if the block is empty. In that case you just get a copy of the record with the same values.

var point = new Point(23, 42, 90, 2, 5);
var copy = point with { };

And just to make sure you can focus on the next part were I make a connection to named parameters, let me also clarify that you can nest with expressions. So for a record Line(Point start, Point end) you can create an instance's copy that's on the x-axis by setting start's and end's y coordinate to zero with the statement: Line xAxis = line with... and now in curly braces reassign start and end. start = start with { y = 0; } and end = end with { y = 0; }.

Named Parameters - Not!

If you squint really hard. And look through a frosted glass of wishful thinking. And then poke yourself in the eyes, you might think this looks like named parameters for constructors. But it's really not, it's just a block of code that prepares variables for an eventual constructor call.

"Whatever" I can hear a few of you say, heading into the weeds. "All I need is a readily available default instance of my record, and I can create all other instances with thatInstance with { $assignments }" and then the assignments look like named record parameters.

record Point(int x, int y) {

	static final Point POINT = new Point(0, 0);

}

var point = POINT with { y = 42; x = 23; };

And you're not wrong. You can do that and it can lead to a nice API. I should know, I already have one that is purpose-built for this exact approach. It models HTML. A paragraph, for example, is a Paragraph record and I declare a p variable that has all components set to null. Then I can create a paragraph with a certain id, for example, with p with { id = "my-id"; }.

record Paragraph(/* ... */) {

	static final Paragraph p = new Paragraph(/* nulls */);

}

var my = p with { id = "my-id"; };

But this only works because a paragraph without any information is a legal value in the domain of HTML and the obvious default instance of a Paragraph record and so I can use it in that idiom. But it is essential to stick to this order of events! First the constraints, then the identification of an obvious default instance, then the cool with construction. If you loosen the constraints even the tiniest bit or anoint one of several reasonable defaults as the chosen one, you hurt your code's correctness and maintainability and readability for zero material benefit. Please don't do this!

And if you're wondering whether this at least opens the door towards named parameters, I got a disappointing link in the description for you, to a mail from Brian Goetz. But I can even do you one better. Here's Brian Goetz disappointing you on video in an AMA we recorded last fall. I see you again in four weeks. Until then, so long...

Embedded video.

Watch the video.

Java 23: Restoring the Balance with Primitive Patterns - Inside Java Newscast #66

Nicolai Parlog — Thu, 04 Apr 2024 00:00:00 GMT

The ongoing introduction of pattern matching to Java has unbalanced the language. Here's how primitive patterns (in Java 23) and other patterns (in future versions) will fix that.

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about primitive patterns in Java 23. Primarily, but we'll also put them in context of the patterns we already got and the ones we will probably get in the future. Because the partial introduction of patterns into Java has unbalanced it and we'll see how future additions will once again bring balance to the force, sorry, the language.

Ready? Then let's dive right in!

Incremental Patterns

The introduction of pattern matching to Java is a great example of incremental development. This is a big feature with wide-ranging implications for how we write code but we see it appear piece by piece.

Type Patterns

First we got type patterns, which allow us to take a variable and check whether it's of a specific reference type and, if it is, create a new variable of that type with the given name.

if (shape instanceof Point p)
	processY(p.y());

Check, declaration, and assignment or extraction - that's the triad of pattern matching. We got type patterns in instanceof and, a few releases later, also in switch.

switch (shape) {
	case Point p -> processY(p.y());
	// more cases
}

Guarded Patterns

The introduction of patterns to switch also brought guarded patterns, which specialize a pattern in a case with additional boolean checks. That allows us to express those conditions on the left side of the arrow, which is great because than all selection criteria can go there while the right side is exclusively concerned with processing the selected variables.

switch (shape) {
	// selection with guarded pattern (left of ->)
	case Point p when p.x() == 0 -> processY(p.y());
	case Point p -> process(p.x(), p.y());
	// more cases
}

Record Patterns

Pushing expressive and succinct selection further, are record patterns. Since a record's state is transparent, Java doesn't only know how to put a record together and can thus generate a constructor, it also knows how to take it apart and record patterns allow just that.

record Point(int x, int y) { }

switch (shape) {
	// deconstruction with record patterns
	case Point(int x, int y) -> process(x, y);
	// more cases
}

Unnamed Patterns

But always listing all record components becomes cumbersome really quickly because you often only need a few of them.

switch (shape) {
	// `x` is declared but unused 😔
	case Point(int x, int y) -> processY(y);
	// more cases
}

Unnamed patterns to the rescue! Simply replace the patterns for the record components you don't need with an underscore and you not only ease writing and reading of the code, you also express unequivocally that you don't care about those variables.

switch (shape) {
	// only used variables are declared 🙌🏾
	case Point(_, int y) -> processY(y);
	// more cases
}

Nested Patterns

When you're putting an unnamed pattern into a record pattern, or a type or record pattern into another record pattern for that matter, you're nesting them. And while that's very natural to do, it's not like the compiler just started allowing that. No, this feature is called nested patterns and was introduced together with record patterns because so far they're the only ones where nesting makes sense.

Summary

So, to summarize:

We can match against reference types.
We can deconstruct records in a way that mirrors their construction.
We can nest patterns within one another where that makes sense.
We can ignore parts of a pattern with unnamed patterns.
We can do all that in instanceof and in switch.
And in switches we can further refine the selection with guarded patterns.

That's all pretty good and you might have heard me describe that (plus sealed types) as the pattern matching basics. But it's only really that: the basics. There are more features to be built on this, but, importantly, this also needs to be built out because what we have so far puts more weight on some parts of the language but not others. So let's turn to what these imbalances are and how Java 23 and beyond are going to address them.

Primitive Patterns

`instanceof`

Historically, instanceof only worked with reference types. Because there's no abstraction over primitives, that makes sense. No variable is "potentially a byte" - either it is declared as one, then it is one, or it's of some other type and then it cannot be a byte.

// in Java <23, this doesn't compile
// in Java <16, it doesn't even make sense
if (x instanceof byte) {
	// ...
}

With the introduction of pattern matching, instanceof changed its semantics, though. It's no longer just "is this variable of that type" - now it means "does this variable match this pattern", meaning does it fulfill a certain condition and asking this question can make sense for primitives. So when the old instanceof would've asked "is this variable a byte?", the answer would always have been "no" (unless it's declared as a byte of course), but now instanceof could ask "can this variable be represented as a byte?" and the answer to that is "yes" for all variables that represent an integer between -128 and +127. This is called a primitive pattern and Java 23 will allow exactly that.

long x = // ...
if (x instanceof byte b)
	System.out.println(b + " in [-128, 127]");
else
	System.out.println(x + " not in [-128, 127]");

The check goes beyond ranges, though. Here's a special number: 16_777_217. It's special because it's the smallest int that cannot be represented as a float. Specifically, creating it as a float will result in 16_777_216.

So you could ask, is 16_777_216 an instance of float? Yes. But is 16_777_217 an instance of float? No. It's within the bounds of float but it cannot be represented. And primitive patterns check this as well!

jshell> boolean is216float = 16_777_216 instanceof float
is216float ==> true
jshell> boolean is217float = 16_777_217 instanceof float
is217float ==> false

This is much better than than what we have now, where we'd have to cast and silently loose information.

`switch`

This fixes the imbalance of reference and primitive types in instanceof that was created by the change in its semantics. But what about switch? You could argue that it was seriously lopsided even before patterns. The list of types to switch over was somewhat eclectic: byte, short, int, char, (wait, where's long?), String, and all enums. Then, recently, we added all reference types to the list but what about long? And float and double while we're at it.

This change fixes that as well. Now all primitives, including booleans, can be switched over. And since there are patterns for them, you can catch their values for additional guards on the left side of the arrow or for ease of use on the right.

Point scale(Point point) {
	return switch (multiplyService.getMultiplier()) {
		case 0.0f -> Point.ZERO;
		case 1.0f -> point;
		case float f when f < 100 -> point.scale(f);
		case float f -> point.estimateScale(f);
	};
}

In accordance with recent developments, switching over one of the newly allowed primitive types or using a pattern in a switch over one of the old types, turns the switch into one that insists on exhaustiveness. That means your switch statement over int doesn't have to cover all cases…

int x = // ...
// switch statement over "classic" type
switch (x) {
	case 0 -> doSomething();
	case 1 -> doSomething();
	// not exhaustive ~> still compiles ☢️
}

…but once you turn it into an expression…

int x = // ...
// switch expression over "classic" type
var result = switch (x) {
	case 0 -> doSomething();
	case 1 -> doSomething();
	// not exhaustive ~> compile error ✅
}

…or switch over long…

long x = // ...
// switch statement over "new" type
switch (x) {
	case 0L -> doSomething();
	case 1L -> doSomething();
	// not exhaustive ~> compile error ✅
}

…or add a pattern…

int x = // ...
// switch statement over "classic" type
// that uses a primitive pattern
switch (x) {
	case 0 -> doSomething();
	case int i -> doSomething();
	// not exhaustive ~> compile error ✅
}

…then it does. That's annoyingly imbalanced on its own but I don't see a fix for that that doesn't break all old switches, so it looks like we have to live with it.

Nested

There's one more place where primitive patterns improve balance and that's in nested patterns. If you deconstruct a record, you don't have to match the component types exactly. Quite the opposite, you can use subtypes of the component types to only select those record instances that hold an instance of that subtype. That used to not apply to primitive components - you had to match those exactly.

record ScaledShape(Shape shape, double scale) { }

switch (scaledShape) {
	case ScaledShape(Shape p, byte s) -> // …
	case ScaledShape(Shape p, long s) -> // …
	// catches all shapes / scales
	case ScaledShape(Shape p, double s) -> // …
}

With the semantics of primitive patterns, that'll be a thing of the past. You can now select those record instances whose component fits, for example, into a byte, regardless of whether it is declared as a byte or any other primitive numerical type.

switch (scaledShape) {
	case ScaledShape(Shape p, byte s) -> // …
	case ScaledShape(Shape p, long s) -> // …
	// catches all shapes / scales
	case ScaledShape(Shape p, double s) -> // …
}

As usual there's a bit more to the topic than I'm covering here, for example a table explaining which primitive conversions are unconditionally exact and which are widening and which are narrowing. For all that, check out JDK Enhancement Proposal 455. It proposes to preview primitive patterns in JDK 23 and is already integrated, so you can download a 23 early access build right now and start playing with them.

Upcoming patterns

So primitive patterns fix an imbalance in how patterns, primitives, instanceof, and switch work. But this doesn't fix all such issues and it turns out that all four upcoming patterns I found in the Amber design documents, link below the like button, can be viewed through the lense of returning balance.

Note:

Of course all upcoming features and their syntax are speculative. No promises. 😉

End Note.

Deconstruction Patterns

For example, we've just talked about how record patterns are the inverse of a record constructor.

/*   ┌─────── → */ new Point(x, y) // ────────┐
//   │         (generated constructor)        │
//   ↑                                        ↓
// values              RECORDS           instance
//   ↑                                        ↓
//   │       (generated record pattern)       │
/*   └─ */ instanceof Point(int x, int y) // ─┘

But where's the inverse of a regular class' constructor? Don't get me wrong, most classes don't lend themselves to this kind of deconstruction, but some do - what about them? Deconstruction patterns are the answer. With them, you can manually define a deconstruction contract, analogues to defining a construction contract with a constructor. Record patterns are then just a special, automatically-generated case of deconstruction patterns.

/*   ┌─────── → */ new StringJoiner(dl) // ───────┐
//   │             (custom constructor)           │
//   ↑                                            ↓
// values                CLASSES             instance
//   ↑                                            ↓
//   │          (deconstruction pattern)          │
/*   └─ */ instanceof StringJoiner(String dl) // ─┘

Static Patterns

So we generalized the conceptual pair "constructor / record pattern" for records to "constructor / deconstruction pattern" for all classes. But some classes prefer not to expose their constructor and have clients go through static factory methods instead - Optional is a good example with of and empty. To mirror that in deconstruction, we may get static patterns, so you could ask, to continue the example, whether an Optional was created of(String s) and the pattern matches if the Optional contains a string.

/*   ┌────────── */ Optional.of(s) // ──────────┐
//   │             (static factory)             │
//   ↑                                          ↓
// values                                  instance
//   ↑                                          ↓
//   │             (static pattern)             │
/*   └─ */ instanceof Optional.of(String s) // ─┘

Instance patterns

Whereas static patterns ask whether a variable fulfills a general (a static if you will) condition, instance patterns go a step further and ask whether a variable fulfills a condition based on some other variable's state. This will be big! Everyday programming contains uncounted statements that implement "if this fulfills that, extract those variables". For example:

If this string matches that regex pattern, extract the groups:

var pattern = Pattern.compile("(.)(..)");
var matcher = pattern.matcher("abc");
if (matcher.find()) {
	var first = matcher.group(1);
	var last = matcher.group(2);
	// ...
}

If this key is contained in that map, extract the value:

Map<String, Point> points = // ...
if (points.containsKey("name")) {
	var point = points.get("name");
	// ...
}

etc, etc.

Instance patterns allow expressing these checks, declarations, and extractions in one concept, making them all more succinct, safer, and potentially atomic thus considerably improving Java code.

var pattern = Pattern.compile("(.)(..)");
// `Pattern::match` is an instance pattern
if ("abc" instanceof pattern.match(String first, String last)) {
	// ...
}

Map<String, Point> points = // ...
// `Map::mapsTo` is an instance pattern
if ("name" instanceof points.mapsTo(Point point)) {
	// ...
}

Constant Patterns

For the last pattern I've found in the documents, assume you switch over a point with x/y coordinates and one branch needs the y coordinate but should only be taken if x is zero. Of course you could extract x and y and use a guarded pattern to check whether x is zero but this is less expressive than it could be. Deconstruction is supposed to mirror construction and there you'd just call new Point(0, y).

/*   ┌─── → */ new Point(0, y) // ──────┐
//   │                                  │
//   ↑                                  ↓
// values   HOW'S THIS SIMILAR?!   instance
//   ↑                                  ↓
//   │                                  │
/*   └─ */ case Point(int x, int y) // ─┘
                            when x == 0

Constant pattern fix this imbalance and allow matching a value to a constant. Somewhat pointless in and of itself, they work great when nested in other patterns. The example I just gave would be simplified to case Point(0, var y). Neat.

/*   ┌─── → */ new Point(0, y) // ──────┐
//   │                                  │
//   ↑                                  ↓
// values       MUCH BETTER!       instance
//   ↑                                  ↓
//   │                                  │
/*   └─── */ case Point(0, int y) // ───┘
//

Outro

Why not download a 23 EA build, link in the description, and give primitive patterns a spin? Using preview features in source file execution has become even easier in 23 because you only need java --enable-preview and can elide --source $number. So it's a text file, a main method, and that simple command to start experimenting. That has never been easier!

And that's it for today on the Inside Java Newscast. I hope you had a good time, if so you can do me a favor and let YouTube know with a like. And if you're not subscribed, why? Do it now and I'll see you again in two weeks. So long ...

Watch the video.

JDK 20-23: Support For Unicode CLDR Version 42

Nicolai Parlog — Fri, 29 Mar 2024 00:00:00 GMT

Java 20 updates its locale data to Unicode CLDR version 42, which comes with formatting and parsing changes, particularly of dates and times

JDK 20 - Support for Unicode CLDR Version 42

The JDK's locale data is based on the Unicode Consortium's Unicode Common Locale Data Repository (CLDR). As mentioned in the December 2022 Quality Outreach newsletter, JDK 20 upgraded CLDR to version 42, which was released in October 2022. This version includes a "more sophisticated handling of spaces" that replaces regular spaces with non-breaking spaces (NBSP / \u00A0) or narrow non-breaking spaces (NNBSP / \u202F):

in time formats between a and time
in unit formats between {0} and unit
in Cyrillic date formats before year marker such as г

Other noticeable changes include:

As a consequence, production and test code that produces or parses locale-dependent strings like formatted dates and times may change behavior in potentially breaking ways (e.g. when a handcrafted datetime string with a regular space is parsed, but the parser now expects an NBSP or NNBSP). Issues can be hard to analyze because expected and actual strings look very similar or even identical in various text representations. To detect and fix these issues, make sure to use a text editor that displays different kinds of spaces differently.

If the required fixes can't be implemented when upgrading to JDK 20, consider using the JVM argument -Djava.locale.providers=COMPAT to use legacy locale data. Note that this limits some locale-related functionality and treat it as a temporary workaround, not a proper solution. Moreover, the COMPAT option will be eventually removed in the future.

It is also important to keep in mind that this kind of locale data evolves regularly so programs parsing/composing the locale data by themselves should be routinely checked with each JDK release.

For more details, please check JDK-8284840.

JDK 23 Update - Loose Matching of Space Separators

From JDK 23 onwards, parsing of date/time strings allows loose matching of spaces. This enhancement is mainly to address the issue described above. Loose matching is performed in the lenient parsing style for both date/time parsers in java.time.format and java.text packages. In the default strict parsing style, those spaces are considered distinct as before.

To utilize loose matching in the java.time.format package, applications will need to explicitly set the leniency by calling DateTimeFormatterBuilder.parseLenient():

var dtf = new DateTimeFormatterBuilder()
	.parseLenient()
	.append(DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT))
	.toFormatter(Locale.ENGLISH);

In the java.text package, the default parsing mode is lenient and applications will be able to parse all space separators automatically (i.e. the default behavior changes with this feature). In case they need to strictly parse the text, they can do:

var df = DateFormat.getTimeInstance(DateFormat.SHORT, Locale.ENGLISH);
df.setLenient(false);

For more details, please check JDK-8324665.

(Dirty?) Tricks in Java 22 - Inside Java Newscast #64

Nicolai Parlog — Thu, 29 Feb 2024 00:00:00 GMT

Pattern matching Optional, expanding sealed type hierarchies, nesting switches, reverting instanceof, and more - so many (dirty) tricks to play around with in modern Java

Can you believe that this Inside Java Newscast has an episode number 1 with six zeroes? One, zero zero zero, zero zero zero - that is so cool! So, for this jubilee episode, should we have some fun? Experiment a bit, explore the boundaries of modern Java, and maybe come up with a dirty trick or two? I say, we should!

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna use, misuse, and abuse a few of Java's latest features. This requires that you already know and understand them, so I'll sometimes post a link to another video, so you can study up if you need to.

Also, some of what we'll end up doing is a bit dirty, so please don't take this as advice to use such code at work. We're here to have fun and to experiment, not to write code for customers. If you don't appreciate the joy of exploration for its own sake, that's fine, but then this episode is not for you, so please no "Why would you do that?" comments. And that includes Reddit - I see you!

Got it? Then let's have some fun!

Expandable Sealed Types

Sealed types let us ensure that we know all implementations of an interface. Say we're modeling HTML and want to have a type for divs, another for paragraphs, another for spans, and so forth, then it makes sense to create an interface HtmlElement that they all implement and that is sealed and permits exactly them as subtypes.

sealed interface HtmlElement permits Div, Paragraph, Span { }

record Div(/*...*/) implements HtmlElement { }
record Paragraph(/*...*/) implements HtmlElement { }
record Span(/*...*/) implements HtmlElement { }

String tag(HtmlElement element) {
	return switch (element) {
		case Div _ -> "<div>";
		case Paragraph _ -> "<p>";
		case Span _ -> "<span>";
	};
}

But what if we want to allow users of our project to expand this type hierarchy? To do that, keep in mind that a type that extends a sealed type must itself be sealed, final, or explicitly non-sealed. And the latter allows arbitrary implementations, so it can act as an extension point in our hierarchy. So for custom HTML elements, we could permit a non-sealed interface CustomElement extends HtmlElement and then users extend from there.

sealed interface HtmlElement permits CustomElement, /*...*/ { }
non-sealed interface CustomElement extends HtmlElement { }

String tag(HtmlElement element) {
	return switch (element) {
		case Div _ -> "<div>";
		case Paragraph _ -> "<p>";
		case Span _ -> "<span>";
		case CustomElement _ -> "<🤷🏾‍♂️>";
	};
}

This creates an issue, though. If we build a fully-sealed hierarchy, we're free to implement all operations on it externally, meaning as methods on some other classes that take types from our hierarchy as input, switch over them, and treat each according to the operation's needs. Compared to adding operations as methods on these types directly, this has the major advantage that we can easily add new operations without changing the types.

But what about those custom types? How do we treat them in our operations?

No really, I'm asking. I don't know any approach that always work elegantly. I can tell you that in the CustomElement extends HtmlElement-example, I ended up adding a method to CustomElement that resolves it to an HtmlElement. So in that case, I expect every custom element to be able to express itself in HTML and then all my other logic can build on that. I'm quite happy with that solution for that specific case but it's obviously not generally applicable.

non-sealed interface CustomElement extends HtmlElement {
	HtmlElement resolve();
}

String tag(HtmlElement element) {
	return switch (element) {
		case Div _ -> "<div>";
		case Paragraph _ -> "<p>";
		case Span _ -> "<span>";
		// let's hope there's no
		// infinitive recursion 🤞🏾
		case CustomElement c ->
			tag(c.resolve());
	};
}

Nesting Switches

The HTML example I just gave? It's actually a bit more complicated: I ended up having to distinguish between three different elements types:

the aforementioned HTML elements
the custom elements users could provide
a limited number of internal elements like pure text

The hierarchy I chose was a top-level interface Element which permits KnownElement and CustomElement. We already discussed CustomElement before, which is the only non-sealed interface in this hierarchy. KnownElement is further split into HtmlElement and InternalElement, both of which permit a dedicated set of records that implement them.

Now, an operation that accepts an Element needs to switch over that. It can say case KnownElement -> ... and case CustomElement -> ... and that covers all cases but is borderline pointless - I want to operate on those records after all. So instead I wrote a case for each record implementing HtmlElement, then a case for each implementing InternalElement, and a final one for CustomElement.

Element element = // ...
switch (element) {
	// HTML elements
	case Div div -> ...
	case Paragraph p -> ...
	case Span span -> ...
	case Image img -> ...
	case Anchor a -> ...
	case ...
	case Text text -> ...
	case HtmlLiteral html -> ...
	case Nothing nothing -> ...
	case CustomElement custom -> ...
}

That covers all possible implementations and the compiler is happy. But here's the thing: That's a pretty long switch and in an effort to make it easier to understand, I added a comment // HTML elements above those cases, a comment // internal elements above those, and an empty line above case CustomElement because I couldn't bring myself to adorn it with the comment // custom element.

Element element = // ...
switch (element) {
	// HTML elements
	case Div div -> ...
	case Paragraph p -> ...
	case Span span -> ...
	case Image img -> ...
	case Anchor a -> ...
	case ...
	// internal elements
	case Text text -> ...
	case HtmlLiteral html -> ...
	case Nothing nothing -> ...

	case CustomElement custom -> ...
}

And then something freaky happened. The unmoored essence of Uncle Bob appeared and screeched "all comments are failures" with a voice like fingernails on a chalk board until I removed them. Because I can express this in code, right?

The switch over the element can consist of three cases for three interfaces HtmlElement, InternalElement, and CustomElement and then the first two cases can point to a nested switch that covers that respective element. The cool part is that, unlike with comments, I can't accidentally put a new record branch into the wrong block. This really is self-documenting code.

Element element = // ...
switch (element) {
	case HtmlElement html -> switch (html) {
		case Div div -> ...
		case Paragraph p -> ...
		case Span span -> ...
		case Image img -> ...
		case Anchor a -> ...
		case ...
	}
	case InternalElement in -> switch (in) {
		case Text text -> ...
		case HtmlLiteral html -> ...
		case Nothing nothing -> ...
	}
	case CustomElement custom -> ...
}

But... it's also very silly to add these functionally pointless intermediate switches, right? That's not bothering just me, right? Right?!

Reverse Instanceof

You already know that instanceof now allows us to declare a variable of the checked type. So element instanceof Div div means we get to use the variable div.

But where do we get to use it, where is it "in scope" as the language nerds would put it? The answer is: everywhere the condition is true. Classically, that's in the if branch ...

HtmlElement element = //...
if (element instanceof Div div) {
	// `div` is in scope
}

... but what happens when we invert the condition? So if (!(element instanceof Div div)). Then in the if branch, element is of the wrong type and div is not in scope but in the else branch it is.

HtmlElement element = //...
if (!(element instanceof Div div)) {
	// `div` is NOT in scope
} else {
	// `div` is in scope
}

Or, maybe we throw an exception from the if branch, don't have an else branch, and then div is in scope everyhwere after the if. 😮

HtmlElement element = //...
if (!(element instanceof Div div))
	throw new IllegalArgumentException();

// `div` is in scope

So if you're one of those people who (like me) like to put their validation checks at the beginning of a method and a type check is one of them, you can negate the type check, throw an exception if the negation is true, and then happily use a variable in the rest of the method that is not declared as a parameter, is not on the left-hand side of a statement but somewhere on the right in the midst of an if. Use, misuse, abuse? You tell me!

Stream Filter By Type

With all that more direct handling of types, I noticed that my need to filter streams by type has increased. So given a stream of HtmlElements, I may want to retain only the Div instances. The filter-then-map combo was always too cumbersome for me, though, so here's what I ended up with:

Stream<HtmlElement> elements = // ...
Stream<Div> divs = elements
	.filter(Div.class::isInstance)
	.map(Div.class::cast);

A StreamUtils class for this and other kinds of handcrafted operations with a static method keepOnly that takes a Class<T> instance as input and returns a Function<E, Stream<T>> in the form of a lambda that takes an element of type E and uses the class instance to check whether the element is actually of type T, in which case it returns a stream of just that element cast to T, otherwise the empty stream. On the use site we statically import the method and just write flatMap(keepOnly(Div.class)).

public static <E, T> Function<E, Stream<T>> keepOnly(Class<T> type) {
	return e -> type.isInstance(e)
		? Stream.of(type.cast(e))
		: Stream.empty();
}

Stream<HtmlElement> elements = // ...
Stream<Div> divs = elements
	.flatMap(keepOnly(Div.class));

Since JDK 16, I could use mapMulti instead of flatMap to avoid the Stream instance with just one element and gatherers offer another alternative, but I never bothered to update the code to that.

Ad Break!

Short ad break! On March 19th, JDK 22 will be released and we'll celebrate that on this channel with a five-hour live stream starting at 1700 UTC. We'll go over JDK 22's final features, the on-ramp efforts, preview features, and we get an update on Graal as well as on projects Babylon, Loom, and Leyden. And we'll even do a bit more. Brian Goetz will give a short keynote, Mark Reinhold will be there, Alan Bateman and Ron Pressler, and lots of other interesting folks. Keep an eye on this channel in the days before to spot the live stream once it's announced and I'll see you there.

Switching Over Optional

Sealed classes and pattern matching are great to model and process alternatives and there's one fundamental alternative at the core of programming that other languages often model this way: something or nothing. A decade ago, in the absence of these language features, Java went a different way, though: a final class with methods like map and orElse that abstract over the alternatives of presence and absence - Optional. What would that look like with pattern matching, though?

Let's imagine a sealed interface Option<T> that permits the two implementing records:

None without any components
Some<T> with a component T value

sealed interface Option<T> permits None, Some { }
record None<T>() implements Option<T> { }
record Some<T>(T value) implements Option<T> { }

Then, when we have an Option instance in hand, we switch over it and write a case None _ for the absent case and a case Some(var value) for the present case, which then processes the unpacked value:

Option<String> opt = // ...
var text = switch (opt) {
	case None _ -> "Empty";
	case Some(var value) -> "Contains: " + value;
};

Look, ma, no map or orElse but the compiler still makes sure I handle both cases and unlike with lambdas passed to ifPresentOrElse, the branches can even throw exceptions!

Too bad we can't use that today. Or can we? Just add a static factory method over to Option that takes an Optional<T> and returns an Option<T>. Then we can write switch(over(optional)) and do our cases.

sealed interface Option<T> permits None, Some{

	static <T> Option<T> over(Optional<T> opt) {
		return opt
			.<Option<T>> map(Some::new)
			.orElse(new None<>());
	}

}

Optional<String> opt = // ...
var text = switch (over(opt)) {
	case None _ -> "Empty";
	case Some(var value) -> "Contains: " + value;
};

Or, better yet, we wait for Java to allow static patterns and then we don't even need Option anymore and can match Optional directly.

Now, you might be comparing that approach to using map, flatMap, etc. or simply ifPresent with get and are probably wondering in which situations you'd prefer pattern matching over the functional or over the imperative approaches that Optional already allows. Good.

Optional<String> opt = // ...
var text = switch (opt) {
	// speculative syntax (there's not even a JEP for this)
	case Optional.empty() -> "Empty";
	case Optional.of(var value) -> "Contains: " + value;
};

Text Block Line Endings

This is a counterintuitive one. What are text blocks for? To write strings that span multiple lines, right? Yes, or to write really long single line strings. Hear me out.

If we end a text block line with a lone backslash, there won't be a line break there and one way to use this is to turn a regular string literal that gets too long for a single line into a text block but prevent the unwanted line breaks with trailing backslashes.

var block = """
	this \
	is \
	one \
	line\
	""";
var literal = "this is one line";
block.equals(literal); // true

Another way to use this is to play with indentation management. If we place a text block's closing delimiter (the three quotation marks) on its own line, we can use their position relative to the rest of the text block to mark which part of the indentation is code formatting and which part should be present in the resulting string. But having the closing delimiter on its own line also adds a newline character to the end of the string and sometimes you just don't want that.

var text1 = """
		string contains
		no indentation
		""";
text1.endsWith("\n"); // true

var text2 = """
		both lines start
		with a tab
	""";
text2.endsWith("\n"); // true

I think the intended way to handle this is to put the delimiter on the last line and then add the indentation we need by calling String::indent on it. But that method uses spaces for indentation and we all know only sociopaths do that, so we need another solution, which is... yeah, you got it, to add a lone trailing backslash to the text block's last line.

var text = """
		both lines start
		with a tab\
	""";
text.endsWith("\n"); // false

Is this still use or already misuse? I'll come back to that in a minute. But since we're already talking about text block line endings, let me address the Windows users among you.

Hey, are you ok? Recent years were tough, I know. Java no longer auto-detects latin1 as default encoding, the centered layout in Windows 11, learning that Linux runs games faster, having to build your project in WSL2 because even a virtualized ext4 is faster than Windows' native file system, and now it's 2024 - the year of Linux on the desktop. I bet... I bet dealing with all that isn't easy. But don't give up, all is not lost. The \r\n line endings will always be there for you. And, if you need to get those in a text block, remember: you can just end each line in \r and Java will do the rest for you.

var text = """
	windows \r
	line \r
	endings \r
	""";

Good Or Dirty?

So which of these tricks are good and which are dirty? And for the dirty ones, which of them could be used anyway if push comes to shove and which are just so bad that they should be killed by fire? I have some thoughts on that but I'm also of the opinion that it's often contextual and that more relevant than somebody telling you their opinion on this is you thinking through the implications yourself. So instead of priming you by sharing my thoughts here, I'll put them in a comment down there and I won't pin it, so it sits between everybody else's opinions on this, which I'm really curious about, so please comment away.

Also, I wanna try something. I recently noticed that YouTube adds a glow to the like and subscribe buttons when people in the video say certain phrases. I wanna give that a try. So, could you please exit your fullscreen and scroll those buttons into view?

Ok, now, please subscribe and smash that like button. And if you have some self respect to spare, please send it my way, I clearly lack any. So long ...

Watch the video.

Does Java 22 Kill Build Tools? - Inside Java Newscast #63

Nicolai Parlog — Thu, 15 Feb 2024 00:00:00 GMT

Java 22 brings multi source-file execution to the platform. It allows us to run programs consisting of multiple source files and even dependencies with just a simple java command. For experienced developers, this will make exploration and experimentation simpler but it's a real game changer for people just learning Java or even just to program: They can now write Java code from single to multiple source files and even add dependencies before they need to consider an IDE or build tool.

Hey, take a look at this:

project-folder
 └─ Hello.java

$ java Hello.java

So, this is a single Java source file and I'm gonna run it with just the java command, right? java Hello.java And it just runs, without compiling it first But you already knew that. Well, let me try something new:

project-folder
 ├─ Hello.java
 └─ Greetings.java

$ java Hello.java

Do you see that file? Greeting.java? Let's rope that one in. I'm gonna run the same command... Boom! Still works. Even changed the output.

Now, that's not all. See this JAR there, in the lib folder? Wait, let me open that up. See that JAR there?

project-folder
 ├─ lib
 │   └─ audience.jar
 ├─ Hello.java
 └─ Greetings.java

$ java -cp "lib/*" Hello.java

I'm gonna use that as well. Now, I need to change the command a tiny bit... there you go: It still works!

And there you have it: Java 22 can launch multiple source files and even their JAR dependencies straight up without requiring us to call javac, let alone jar. Does that toll the bell for Maven and Gradle?

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and to answer my own question, does this feature kill build tools? No, of course not! What a ridiculous, clickbaity question to ask!

But it does push their use back a bit and in the right circumstances, that's very good. I'll explain later what I mean by that. First, let's explore how this new feature works. Ready? Then let's dive right in!

Launching Multiple Source Files

You've already seen the gist. Since Java 11 you can in-memory compile and then launch a single source file with just the java launcher by passing the path to the source file. What's new in 22 is that if that file references classes from other files, Java will go looking for them and, if it succeeds, keep compiling and executing.

Let's see how it finds those files, though. In the example I showed you, the initial source file (that's the one I passed as a launcher argument) contains no package declaration and is thus in the unnamed package. In that case, Java considers the folder containing it the so-called source tree root and will resolve all referenced classes from there:

It will expect other classes in the unnamed package to also be directly in that root directory.
For classes in named packages, it will map the package to a folder hierarchy in the common way, where each package name section corresponds to a folder, and anchor that hierarchy in the root, and look for the class in the resulting path.

project-folder # ③ source tree root
 ├─ org # ⑦ searched in folder hierarchy …
 │   └─ example # … that matches pkg name …
 │       └─ Audience.java # … anchored in root
 ├─ Greeting.java # ⑤ searched in root
 └─ Hello.java # ① initial source file

$ java Hello.java # ① initial source file

// Hello.java
// ② no package declaration ⇝ unnamed package
class Hello {

	public static void main(String[] args) {
		System.out.println(
			Greeting.get() // ④ in unnamed pkg
				+ ", "
				+ org.example.Audience.get()");
				// ↑↑↑ ⑥ in a named package
	}

}

If classes are not found in these locations, we'll get an error. Simple enough and corresponds to our intuition, I think.

If the initial file declares a package, the file must be in the folder hierarchy that matches the package name as just described. From there, determining the source tree root is a bit more involved, but I'll spare you the details (this time I did look them up, though), because it's just a bit of back and forth to implement the same intuition: The folder that contains the directory hierarchy that corresponds to the package name is considered root.

project-folder # ③ source tree root based on …
 └─ org         # … walking up org/example/ …
     └─ example # … (matches the package name) …
         ├─ Audience.java
         ├─ Greeting.java
         └─ Hello.java # … from initial src

$ java org/example/Hello.java # ① initial src

// Hello.java
// ② package name
package org.example;
class Hello { /* ... */ }

The cool thing about Java not simply interpreting the working directory as the source tree root is that no matter from where you launch the program and which path you have to specify to get to the main class, as long as the structure of the project is ok, the program will run.

project-folder
 └─ org
     └─ example
         ├─ Audience.java
         ├─ Greeting.java
         └─ Hello.java

# All these commands work

# from home/nipa/code/project-folder:
$ java org/example/Hello.java

# from home/nipa/code:
$ java project-folder/org/example/Hello.java

# from home/nipa/code/project-folder/org/example:
$ java Hello.java

Launching With Dependencies

Adding dependencies into the mix is straightforward. Just use the launcher option --class-path or its short form -cp and point to the folder that contains the JARs.

No, wait, that won't work, actually, because the class path doesn't understand what a folder is. You'll have to point into the folder with $folderName/* and at least on Linux you need to quote that to avoid expansion by the shell. So if your JARs sit in the lib folder, add -cp "lib/*" to the java command; or \ for you Windozers.

project-folder
 ├─ lib
 │   └─ audience.jar
 ├─ Hello.java
 └─ Greetings.java

$ java -cp "lib/*" Hello.java

// Hello.java
class Hello {

	public static void main(String[] args) {
		System.out.println(Greeting.get() + ", " + org.example.Audience.get());
	}

}

// Greeting.java
class Greeting {

	static String get() {
		return "Hello";
	}

}

Compilation Odds & Ends

There are few more odds and ends when it comes to compilation:

Java only compiles files that are directly or indirectly referenced from the initial file, which means you can have source files with compile errors lying around in the same folder hierarchy as long as you don't reference them and the program will still run.
There are no guarantees in which order different files are compiled or whether that even happens before or after main started executing.
This "compiling on the fly" means that you can get compile errors during program execution, which is something we're not used to.

And then there are a few odds and ends beyond that, but I'll leave those for you to study. One interesting aspect hidden in these details is the design philosophy. It's not just "make things easy", it's also "make the transitions from single-source to multi-source and from multi-source to JARs" smooth. Those steps should feel natural and come with no or only minimal readjustments to the new situation.

But... Why?

Now that we better understand the mechanics of multi source-file execution, let's discuss why it was introduced. That was the work of JDK Enhancement Proposal 458, by the way, link in the description - just below the like and subscribe buttons. Oh, and this is no preview feature, it's final in JDK 22.

But back to why. This just does a bit of work that IDEs and build tools already do, right, so what's the point? For experienced developers in situations where quickly setting up a new project in those tools is no hassle, there is no point. Just keep doing what you're already doing.

But maybe you're experimenting with a new feature, are participating in Advent of Code, want to figure out the fastest way to parse 1 billion rows, or are exploring an unknown problem space in the hope of arriving at a prototypical solution. Then a light-weight editor and a few flat files may just be the way to go; at least for a while. And with this addition to single source-file execution, you can go much further before you need to force your exploration into a structure that a build tool is happy with - only really when you need to manage dependencies or create an artifact.

And while pausing to add some structure and set up tools may break the flow of an experienced developer, it's not much more than an annoyance. But imagine you're just starting out, trying to understand basic programming concepts, the Java language, some APIs, and as soon as you're confident enough to write a program that spills over into a second file, you have to pause and learn what a build tool or IDE is, how it works, which one to use, how to set them up, etc. For newbies this is a real roadblock.

I still remember how shocked and awed I felt when I first saw Eclipse and a POM. And that's not their fault, by the way! Properly building a project comes with complexity. And so it's very cool that this addition defers that complexity until you actually, you know, want to build a project and not just run a bit of code.

Outro

And that's it for today on the Inside Java Newscast. I'm at Jfokus right now and we're going to record a bit more here, I reckon, so say tuned, subscribe, so you don't miss those videos and I'll see you again inb two weeks. So long ...

Watch the video.

The Hottest Language You Didn't Have On Your Radar

Nicolai Parlog — Mon, 05 Feb 2024 00:00:00 GMT

With so much going on in the programming language space, it's easy to miss any specific language's success story and so in this talk I want to put a particularly hot one on your radar

New programming languages come up all the time and the top dogs they want to supplant are constantly evolving to beat them back. With so much going on, it's easy to miss any specific language's success story and so in this talk I want to put a particularly hot one on your radar:

Its REPL, three-line hello-world, single-command project execution, built-in webserver, and excellent VS Code support make it easy to get started.
Lambda expressions, one-line type declarations, top-class pattern matching, and other modern language features makes it fun to stick around.
It has a strong, nominal type system that is there for you when you need it and takes a step back when you don't.
Generate projects via web and IDE UIs or with just a few terminal commands and enjoy development without nasty compile/reboot cycles.
Whether you need fast startups, high peak performance, massive concurrency, or ultra-low 99th percentiles, there's a configuration that achieves your goals.
Or is it native interop, CPU-vector instructions, and GPU offloading you're after? It's got you.
And I won't even get to the battle-tested IDEs, build tools, test or web frameworks, and the amazing open-source community.

So what language am I talking about? You wanna sit down for this: It's Java. 😱

Did I exaggerate a bit? Am I overenthusiastic? A paid shill? Yes, but that doesn't make me wrong. 😁 I promise, if you haven't touched Java in a while or only heard horror stories about it, you'll be surprised to see how far it came and how great it really is. Let me show you.

Java 22 Previews Statements Before super(...) and this(...) - Inside Java Newscast #62

Nicolai Parlog — Thu, 01 Feb 2024 00:00:00 GMT

Whether for validation, preparation, or splitting and sharing arguments, it can be quite annoying that Java doesn't allow statements before the super(...) or this(...) call in a constructor. Luckily Java 22 is about to change that with JEP 447, which previews statements before the explicit constructor invocation.

By a show of hands, who occasionally puts code before the super(...) or this(...) call when writing a constructor, only to be yelled at by the compiler?

class Name {

	private final String first;
	private final String last;

	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

	// Version A - doesn't work on JDK ≤21
	Name(String full) {
		var names = full.split(" ");
		this(names[0], names[1]);
	}

	// Version B - works but repeats code
	Name(String full) {
		this(full.split(" ")[0], full.split(" ")[1]);
	}

}

Just me? Oops. But surely you occasionally want to put code there? My favorite scenario to get angry over is when a constructor that is meant to ease use of a class needs to split an argument in two and then pass each part on to the "real" constructor. Trying to put that logic into code feels like playing golf with a bowling ball. But whether it's for such more "complicated" uses or just to validate or prepare arguments, it would be really handy to be able to start a constructor with some code before calling a super constructor with super(...) or another one from the same class with this(...). Lucky us, or still just me? (Just you!) (That actually sounds interesting, let's hear him out.) So, lucky us, then, Java 22 will preview exactly that.

Intro

Welcome everyone, to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we'll have a look at JDK Enhancement Proposal 447, which is integrated into JDK 22, so come March, you'll be able to use it as a preview feature. Let's divehhh... I can't with those two guys staring at me disapprovingly. Also, the weather is really great, so why not go outside and check in on those cows. Let's go!

(Yes, the whole setup with the milk and with the hike was just to show you these two cows. There're usually way more here on that field.)

Constructor Chaining

Before we get into what's new we should recap how things stand today when it comes to constructor chaining. Maybe we'll start right there: Constructor chaining is the technique of calling one constructor from another, often in a chain until all calls land in the same canonical constructor, but that last part is not required.

class Name {

	private final String first;
	private final String last;

	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

	Name(String last) {
		this("", last);
	}

	Name() {
		this("");
	}

}

In the case of class inheritance, chaining is enforced: A subclass constructor must call a superclass constructor with a super($ARGUMENTS) statement. You don't always have to type that out, though - if the superclass has a parameterless constructor, the compiler will let you get away without calling it explicitly and will slip it into the generated bytecode. Note that this applies to all classes we write because, if nothing else, they still extend Object.

You can also call constructors from the same class with a this($ARGUMENTS) statement. And while records actually require that, regular classes don't. In that case, every constructor can decide whether it wants to assign fields itself or forward to another constructor. For what it's worth, I prefer the latter, but due to the limitations we'll come to momentarily, that's not always feasible.

class Name {

	private final String first;
	private final String last;

	// canonical constructor, assigns fields itself
	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

	// Version A: forwards to the canonical constructor
	Name(String last) {
		this("", last);
	}

	// Version 2: assigns fields itself
	Name(String last) {
		this.first = "";
		this.last = last;
	}

}

By the way, I don't always want to say "super(...) or this(...) statement", so I'll switch to the technical term, which is "explicit constructor invocation". Actually, I'll cut that even shorter to the less precise "constructor invocation".

No Statements Before Constructor Invocation

So what code can be executed before a constructor invocation? Because you can't put any statements before it, you might be tempted to say "none" but it's not actually that bad. You can use expressions for the invoked constructor's arguments as long as they don't touch instance members of the object being constructed. In practice that often means having a small Stream or Optional pipeline or calling static methods like Objects::requireNonNull.

Those expressions may validate arguments before passing them on, or they may process them and pass on derived values. As long as there's a clear 1:1 relationship between the received and the passed arguments, not being able to write statements before the constructor invocation can be annoying but easily worked around by calling dedicated static methods. And if those methods do something non-trivial and have a good name, you could even argue it's cleaner than putting everything into the constructor. But once you need to split arguments or create shared instances, it really gets nasty. Then you're suddenly knee-deep in inner classes and auxiliary constructors.

class Name {

	private final String first;
	private final String last;

	Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

	// a constructor-based solution
	// that avoids two splits
	Name(String full) {
		this(full.split(" "));
	}

	private Name(String[] names) {
		this(names[0], names[1]);
	}

}

We'll see later how much better that works with JEP 447.

But why are the rules so strict? It's most obvious for super(...) calls: Subclasses depend on the state of their superclass, for example when calling methods or accessing fields, and to make sure that works out during construction, the superclass must be initialized before the subclass does anything. And the easiest way to enforce that no-access-before-initialization rule is to enforce a strict top-down execution of constructors, which means no statements before calling super(...).

It's less obvious for this(...) calls but boils down to the same reason. If a constructor could have statements before calling another with this and that one... this one... the other one would call super (which, remember it must do eventually), we'd still have statements in the subclass before the superclass constructor gets executed. So no statements before calling this(...) either.

JDK Enhancement Proposal 447

After explaining all that, JEP 447 comes to a conclusion:

If the Java language could guarantee top-down construction and no-access-before-initialization with more flexible rules then code would be easier to write and easier to maintain. [...] We need to move beyond the simplistic syntactic requirements enforced since Java 1.0, that is, "super(..) or this(..) must be the first statement", "no use of this", and so forth.

The JEP formulates those more flexible syntactic requirements by conceptually splitting the constructor into three blocks:

the prologue contains the statements before the explicit constructor invocation
then comes the invocation itself
and finally, the remaining statements are called the epilogue

The invocation and the epilogue already exist today and nothing changes for them. The prologue is new, though, the compiler used to accept no statements there at all. That changes now - you can have a non-empty prologue that does all kinds of things.

But it's no free for all. As a rule of thumb, assume you're in a static context, meaning you can do everything in a prologue that you could do in a static method. It's actually a bit more than that - the JEP proposes a new pre-construction context - but the exact rules for what statements are allowed are a little complicated and even the JEP doesn't explicitly list them, so I'm not going to go into them here (which is code for "I didn't look them up").

JEP 447 proposes to allow, as a preview language feature, statements that comply with this pre-construction context before explicit constructor invocation. And as I mentioned, this is a preview feature in JDK 22.

Prologue Benefits

So with that feature in play, we can now do a number of common tasks more simply.

To validate arguments, we no longer have to push the validation logic into a static method that gets called in the constructor invocation, although in many situations that may still be the way to go for succinctness.

class ThreePartName extends Name {

	private final String middle;

	// JDK ≤21
	ThreePartName(String first,
	              String middle,
	              String last) {
		// can't have a middle name
		// without first name
		super(
			requireNonNullNonEmpty(first),
			last);
		this.middle = middle;
	}

	// JDK 22 + PREVIEW FEATURES
	ThreePartName(String first,
	              String middle,
	              String last) {
		// can't have a middle name
		// without first name
		requireNonNullNonEmpty(first);
		super(first, last);
		this.middle = middle;
	}

}

Likewise, preparing arguments like stripping a string or rearranging a collection can be done in the prologue now, but in some cases may still be embedded in the constructor invocation as long as the code remains readable.

class ThreePartName extends Name {

	private final String middle;

	// JDK ≤21
	ThreePartName(String first,
	              String middle,
	              String last) {
		// shorten first if middle is given
		super(middle.length() == 1
				? first.substring(0, 1)
				: first,
			last);
		this.middle = middle;
	}

	// JDK 22 + PREVIEW FEATURES
	ThreePartName(String first,
	              String middle,
	              String last) {
		// shorten first if middle is given
		var short1st = middle.length() == 1
				? first.substring(0, 1)
				: first;
		super(short1st, last);
		this.middle = middle;
	}

}

Where the prologue really shines is with sharing and splitting arguments, though. No longer is it necessary to add inner classes or auxiliary constructors just to get those things done.

class ThreePartName extends Name {

	private final String middle;

	// JDK ≤21
	ThreePartName(String full) {
		// split "first middle last"
		// on space (three times! 🤦🏾‍♂️)
		super(
			full.split(" ")[0],
			full.split(" ")[2]);
		this.middle = full.split(" ")[1];
	}

	// JDK 22 + PREVIEW FEATURES
	ThreePartName(String full) {
		// split "first middle last"
		// on space (once 🙌🏾)
		var names = full.split(" ");
		super(names[0], names[2]);
		this.middle = names[1];
	}

}

So, yeah, definitely not a game changer but once again a nice little quality of life improvement. And as is so often the case, it comes with a chance to better understand Java and the reasons behind its limitations, which I often find just as interesting as the change itself. And since you're still here, I reckon you're feeling the same. Thanks for watching this video all the way through and for liking and subscribing. I'll see you again at Jfokus or otherwise right here on the Java YouTUbe channel in two weeks. So long...

Hah, I found them! See, there are more than two after all, I didn't imagine them.

Watch the video.

Java's Plans for 2024 - Inside Java Newscast #61

Nicolai Parlog — Thu, 18 Jan 2024 00:00:00 GMT

In 2024, Java keeps evolving. Here's what the big OpenJDK projects (Amber, Leyden, Valhalla, and more) plan for this year and how that will push Java forward.

Happy Gregorian new year, everyone, and welcome to the Inside Java Newscast, where we cover recent (and in this case future) developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about Java's plans for 2024. Or, more specifically, what the big OpenJDK projects will be working on this year - of course, there's much more development going on.

And note that "working on this year" is very different from "releasing this year", not least because for a feature to be released in 2024, it has to be finished and merged into the JDK main line by mid June, so more than half of 2024's completed work won't even be released before 2025. The last caveat is that nobody can predict the future, least of which software developers, which is why the smart folks in OpenJDK usually don't. Luckily for us, I'm not that smart and so I'll predict all kinds of things in this video, which makes all errors mine. Ready? Then let's dive ... Oh wait, by the way I recorded this in a city where I recently gave a talk at the local Java User Group - I'll let you guess where I was. Now: Let's dive right in!

Babylon

During the JVM Language Summit last August, Paul Sandoz presented code reflection, an expansion of the reflection API that allows access, analysis, and transformation of Java code inside a method. Its goal is to allow developers to write Java code that libraries can then interpret as a mathematical function, for example to differentiate it, which is common in machine learning, or they can transform it to a GPU kernel, to part of an SQL statement, or to anything else, really. I covered this in some detail in Inside Java Newscast #58.

Later in 2023 Paul's exploration led to the foundation of Project Babylon and just this week he has pushed a prototype to the Babylon repository. There's a link to his email announcing that and some context in the description. Over the coming weeks, the Babylon team plans to publish work for a few use cases like auto differentiating, a C# LINQ emulation, and GPU programming in Java. Babylon is still in its early stages, though, so I don't expect anything tangible in the main line in 2024.

Embedded video.

Loom

It feels a bit mean but I think it is fair to say that Project Loom's days in the spotlight are coming to an end. Virtual threads are final and the structured concurrency and scoped values APIs are in their second preview in JDK 22 and I expect them to finalize some time this year. While we start using these features in our code, what remains to be done for the project are various improvements, either under the hood or as additions to these APIs. And while they're minor relative to Loom's overall scope, that doesn't mean they're not important.

I hope specifically that there'll be progress on making synchronization non-pinning and file I/O non-capturing, at least on Linux with io_uring. I don't know whether that progress will be sufficient for a release in 2024, though - the JDK 23 fork is just five months away, after all. But maybe for the next release after that? I'm crossing fingers - or rather, pressing thumbs, because that's what we do in Germany.

Leyden

The last time we walked through the snow, I told you about Project Leyden's concept of condensers.

A condenser is an optional transformation phase that takes a code artifact (like bytecode) as input and produces another artifact as output that can contain new code (like ahead-of-time compiled methods), new data (like serialized heap objects), or new metadata (like pre-loaded classes). The condenser:

performs some of the computation expressed in the input artifact, thereby shifting that computation from some later phase to the current phase

applies optimizations enabled by that shift so the new artifact is faster, smaller, or otherwise "better"

and it possibly imposes constraints but more on that later

In 2023, Leyden made progress researching potential condensers and at JVMLS Mark Reinhold and John Rose presented some considerable performance improvements, where they shortened a Spring Boot app's time to "Hello World" by 50-80%. And the cool thing about these improvements is that they require absolutely no constraints - they work with all of Java's features, even the most dynamic ones! In 2024, Leyden works to bring these benefits out of their prototype state and to deliver them to us, but it's hard to say whether we can expect anything tangible to land this year.

Embedded video.

Amber

Project Amber stays the powerhouse behind Java's language evolution. It currently has three features in preview:

string templates
simplified main (both in their second preview)
statements before this() and super() (which is in its first preview)

I expect all three to finalize in 2024, although not necessarily in JDK 23.

One feature that isn't on that list yet and that I'm very excited about are with expressions. You know that anti-pattern of declaring setters for all fields? (Yes, I called it an anti-pattern - don't @ me.) This doesn't work when fields are final and so, in those situations, you'd want to create methods that accept a value and return a new instance where all fields have the same value as the current instance except for the one that was passed in. So for a class Name with final fields String first and String last, you'd create a method withFirst(String first) that returns a new Name(first, this.last) and similarly withLast(String last) that returns a new Name(this.first, last).

public class Name {

	private final String first;
	private final String last;

	public Name(String first, String last) {
		this.first = first;
		this.last = last;
	}

	// [...]

	public Name withFirst(String first) {
		return new Name(first, this.last);
	}

	public Name withLast(String last) {
		return new Name(this.first, last);
	}

}

Methods like these, often called "withers", are useful but quite boilerplate-y, which is made worse by the advent of records which always have final fields and thus almost require withers. To alleviate that, Brian Goetz' three year old white paper "Pattern Matching in the Java Object Model" described with expressions. They start with a record reference followed by the situational keyword with and a code block. At runtime, they take the record apart into its components and declare a mutable variable for each that is accessible in the code block, which then gets executed. The block can contain arbitrary code but its main function will be to assign new values to at least one of the variables. When it ran its course, the with expression will create a new instance of the record from those variables. So when you have a Name instance called userName, you can create a copy with the same first but no last name, by running var userFirstName = userName with { last = ""; };.

public record Name(String first, String last) { }

var userName = new Name("Jane", "Doe");
var userFirstName = userName with {
	// implicitly declared variables:
	//     String first = "Jane";
	//     String last = "Doe";
	last = "";
	// block returns:
	//    new Name(first, last)
};

So this feature has been in the pipeline for a while, but as far as I can tell, pattern matching was simply more important. But now that the basic building blocks for that are all final in JDK 21, I'm really hoping for withers to be tackled next and to hear more details about them in 2024.

Speaking of pattern matching, though, you can see from the list of in-flight features that work on it took a little breather. But Brian Goetz, Gavin Bierman, Angelos Bimpoudis, and the other folks working on this are already taking the next steps. There's a JEP for a first preview of primitive types in patterns and it's already proposed to target JDK 23. That's JEP 455, link below the like button, and I'll tackle it in a future Newscast, so make sure to subscribe.

And then there was a really interesting mail from Brian Goetz on the Amber mailing list in December: It considered expanding switch to handle exceptions that occur when evaluating the selector expression - that's the method calls you can put into the parenthesis after switch. And Brian also promised us deconstruction assignments a while back!

Although at this point we might be crossing over from "plans for 2024" into "Nicolai's wishlist", so I'll stop here. But it's clear that Amber's not slowing down and will keep shaping Java's evolution.

Valhalla

I still remember the old days, when I was a young whippersnapper, and thought Valhalla is just around the corner and Brian Goetz was just too careful to admit it. Now, three decades later (ok, it's not that bad), I start to see his wisdom, though. There have been a number of proposals that seemed good at the time but whenever one entered the home stretch, it turned out that this is a relay race and they weren't the last proposal after all. Because with every new prototype, new revelations occurred and a better proposal was possible. And I'm giving Brian and his team a lot of credit for not doing the easy thing and just shipping something to get Valhalla over the finishing line but to work out the best possible solution.

Is the current round of proposals it? I wanna say yes, but maybe I'm just falling into the same trap again. But either way, I can tell you what will be worked on - whether that'll be what ends up in the JDK or when that happens is beyond me.

Work will be focused on JEP 401: "value classes and objects". Instances of value classes will be shallowly immutable and lack identity which will often make sense when modeling a domain, will categorically prevent certain kinds of bugs, and will give the JVM much more freedom to encode simple values in ways that improve memory footprint, locality, and garbage collection efficiency.

Beyond that there's the idea to enable nullness markers to get better heap flattening for value objects - the issue and a conversation about that are linked in the description - and of course generic specialization, but I doubt we'll see public progress on these as there's little reason to work on specifics until JEP 401 is stable.

Panama

Project Panama has three irons in the fire:

The vector API is very stable for now and basically production-ready but because it is very likely to change once Valhalla lands, it is still in incubation and sadly, I don't expect that to change in 2024.
The foreign function and memory API, FFM for short, finalized in JDK 21 but is still being improved. For example, the team is currently working on a concept that allows user-friendly and performant mapping between native memory segments and Java abstractions such as records and interfaces.
And then there's jextract, the tool that generates FFM bindings from native library headers. Improving it and the tooling around it will make working with native libraries much simpler than before and is the main focus of Panama in 2024.

Lilliput

Every object on the heap has a header. Project Valhalla aims to introduce optimizations that greatly reduce or even eliminate the need for header bits for specific value type instances and Project Lilliput aims to reduce header size for all regular objects, first to 64 and eventually to 32 bits. I made a Newscast about Lilliput last year and project lead Roman Kennke gave a great talk about it at JVMLS, both linked in the description. In 2023, Lilliput merged an alternative fast-locking scheme, which is needed to later allow the intended reduction of header size. That scheme needs further improvements before it's ready for prime-time, though, and so Lilliput is currently working on that and it seems to me that that'll take much of the year, so I don't expect the header size improvements to land in 2024.

Embedded video.

Outro

And that's it for Java's plans in 2024. Leaving Amber and Valhalla aside, I heard most of you are looking forward to Babylon the most. I gotta say, from that list, my favorite is Leyden. Let's see who gets to release an improvement first.

Talking about improvements, you may have noticed that the Inside Java Newscast changed its look and feel in recent weeks. I got a bit bored by the old style and wanted to shake things up a bit. I'm super interested to hear what you think about it.

I'll see you in the comments and on screen again in two weeks. So long ...

Watch the video.

Java Highlights of 2023 - Inside Java Newscast #60

Nicolai Parlog — Thu, 21 Dec 2023 00:00:00 GMT

2023 is coming to a close and it was quite a year for Java! Let's look back at some of the highlights: on-ramp improvements, why Java 8 is dying, JVMLS, community achievements, and how cool our YouTube channel is. 😊

2023 is coming to a close and it was quite a year for Java! JDK 21 released to great fanfare, finalizing both virtual threads as well the pattern matching basics. There were also some amazing conferences, new Java champions, and we achieved some milestones on this channel, too. Oh, and I'm officially calling it: 2023 was the last year, where it was still reasonable for most projects to be on Java 8.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and it's time to look at some of Java's highlights in 2023. Of course, the ecosystem is way too large to cover all that in about 10 minutes, so I'll focus on a few things that I find most noteworthy. For everything I've left out or missed, I'm relying on you to post your highlights in the comments. Ready? Then let's dive right in!

On-Ramp

Language, APIs, VM, usability, efficiency, performance - Java is improving in many different areas. One recent addition to the to-do list has been approachability and in 2023 a lot has happened here. After JShell in 2017 and single-source-file execution in 2018, this past year has built a few new sections of the on-ramp from early programming to the highway of full-blown Java:

At the very beginner-end of the on-ramp waits the loosened launch protocol that gets away with just the top-level method void main() { ... }, which means Java newbies don't have to either ignore or learn about visibility, classes, static, arrays, or parameters. Just write a very simple method signature and off you go.
At the farther end of the on-ramp is the ability to directly launch not just one but now multiple source files (even with dependencies) directly, meaning without having to compile them first. This means learners, experimenters, and prototypers can stick with just an editor and the Java launcher until they need to build JARs, at which point a build tool is probably still the best option.
Then we have the official Oracle VS Code extension for Java, which offers quicker adoption of new Java releases, better Gradle integration, and an overall much smoother development experience. Meeting developers, especially young ones, where they are is important and for many of them, that is VS Code, so it's good that there's an option that supports all the latest Java features early and reliably.
Last but not least, there's the Java playground. Need to experiment with a new feature, explain a language construct to a beginner, or quickly figure out with a colleague how an API works? Just head to dev.java/playground, write your code, and get your output - all you need is a browser.

The importance of keeping Java accessible, a good language to learn programming with, is hard to overstate and I'm glad we're seeing progress in this area. If you want to learn more about this, there are some follow-up links in the description, for example to my video on simplified main and to Ana's video on the VS Code extension.

Embedded video.

Java Version Adoption

I talk a lot about new Java features: on this channel, at conferences, in articles, ... really everywhere where people listen and even some places where they don't. Probably the second most common reply I get is "I'm still on Java 8" - often with gallows humor, sometimes resignated, and occasionally accusatory as if that's somehow my fault. And the numbers bear that out - not that it's my fault but that Java 8 is still dominant. All surveys suffer from self-selection bias but as far as I can tell, it's the best data we have, and, for example, the recent JetBrains ecosystem survey indeed shows that Java 8 is still the most common version, used by half of all developers. But it's worth looking beyond that and examining the report and those from past years in a bit more detail.

	2018	2019	2020	2021	2022	2023
Java 6	8 %	5 %	3 %	2 %	2 %	1 %
Java 7	33 %	13 %	7 %	6 %	3 %	2 %
Java 8	84 %	83 %	75 %	72 %	60 %	50 %
Java 9	18 %	14 %	6 %	4 %	1 %	1 %
Java 10		13 %	6 %	2 %	1 %	1 %
Java 11		22 %	32 %	42 %	48 %	38 %
Java 12			10 %	4 %	2 %	2 %
Java 13			14 %	4 %	2 %	2 %
Java 14				8 %	3 %	2 %
Java 15				14 %	4 %	2 %
Java 16					6 %	3 %
Java 17					30 %	45 %
Java 18						8 %
Java 19						8 %
Java 20						11 %
Java 21

Total	143 %	150 %	153 %	158 %	162 %	176 %

First, note that the usage percentages sum up to 150-170% as developers could reply with more than one version, which already puts the 50% in perspective. Then, there's a clear downward trajectory for Java 8: It has lost 1/6th of its share in each of the last two years. If it keeps going like this, it will be at 30% in 3 years.

Another reason why 8 is superficially dominant is that there's no clear winner takes all past it. 11 was first covered in the 2019 report, where it already had 22%, which it then grew to 48% last year before dropping in 2023 because people migrated to 17. That even started with 30% in 2022 and went to 45% this year. That means newer Java versions seem to get picked up quicker, a trend I'm expecting to hold for 21. Then there's a consistent 10-15% of developers on the most recent version even if it doesn't get long-term support from anybody, which delights me to see. On the other hand, the 20-25% on versions that were at that point unsupported are a bit worrying.

So if you've been keeping track, while in 2023 Java 8 stood at 50%, newer versions combined where at 120%. In fact, already the 2021 report shows that versions past 8 are more common than 8 with 78% versus 72%.

As I mentioned at the top, surveys like these are not representative, so I don't care about the specific numbers too much. But the trends are clear:

Java 8 user share drops significantly
newer versions combined see strong adoption and very likely already overtook 8
the latest version with LTS see great and arguably increasingly fast adoption

And I'm pretty happy with those trends. I was even foolish enough to extrapolate them into the future. See the pinned comment for my predictions for the 2024 survey - I'm curious to read yours.

Java 6: 1% (because, of course)
Java 7: 1%
Java 8: 38% (slightly faster reduction due to waning support from libraries and frameworks)
Java 11: 25% (no good reason to be on 11)
Java 17: 42% (slightly more moving to 21 than coming from 8 and 11)
Java 21: 35% (21 in 2024 can do better than 17 in 2022! 😃)
Java 22: 12%
$unsupported: 18% (although it should be 0!)

But it's not just that development that tolls the bell for Java 8. A plethora of open source projects upped their minimum Java version requirement beyond 8, many of them this year. The few I had on my list were:

Spring 6 and Spring Boot 3, which require Java 17
Helidon 4, which requires 21
Quarkus 3 requires Java 11 and 3.7 will require 21
Jakarta EE 10 requires Java 11 and JEE 11, scheduled for mid 2024, will require 21

"Surely there are more", I thought, and asked on social media and, damn, did I get a lot of replies! Thank you all for that.

with Java 11 requirements we have Wildlfy 30, Microprofile 6, Debezium 2, Caffeine 3, Bootique 3, non-Enterprise jOOQ 3.19, the Selenium Grid, Dropwizard 3, Hazelcast 5.3, Jetty 10, and Apache Tomcat 10.1, Cayenne 5, Kafka 4, Jena 4, Log4J3, and Storm 2.6 - that felt like a countdown
requiring Java 17 are Jetty 12, Jaybird 6, Netty 5, AssertJ 4, Vaadin 24, Selenide 7, Apache Spark and Camel 4 and OpenNLP 2.3
Tomcat 11 will target JEE 11 and will thus also require Java 21

With the Java 8 user base dwindling, I only expect this process to accelerate, so if your project is still on 8, not only is it soon becoming a minority, it will also see its dependencies move out from under it, which will only make the eventual update harder. I really think 2023 was the last year, where it was still reasonable for most projects to be on 8.

JVMLS is BAck!

So there was no JavaOne this year, which, if I can be frank, sucked. But the JVM Language Summit made a return! In early August, 100 of the smartest people our community has to offer met in Santa Clara, USA to discuss where Java and the JVM are going in the coming years. Whether Java on the GPU, start time and header size improvements, code reflection and the class-file API, or behind-the-scenes insights into value types, virtual threads, and the foreign function and memory API - this was a cornucopia of Java insights! Being much, much, much further down the list of smartest people, I wasn't there but luckily most talks were recorded and published to this channel. I link the playlist in the description.

But JVMLS was not the only conference with a big year in 2023. For more on that and other community achievements, let's switch to Shar.

Community Achievements

The holiday season is upon us as another year comes to a close. And here on the Java Developer Relations Team, as we continue to deliver a variety of technical and community content out to all of you, we also wanna highlight many of the contributions made throughout the year by the Java community. So in the holiday spirit, sit back and let us acknowledge some of those important milestones and people.

Boy, what a year 2023 has been for events and conferences! So many of them celebrated special anniversaries. First off, I'd like to say Happy 10th birthday to Devoxx UK! Happy 20th birthday to Devoxx Belgium! And happy 10th birthday to Devoxx Morocco! And how can we forget, a happy 20th birthday to JFall! I'd like to say thank you to all the event organizers, Java User Group leaders, and volunteers that made these experiences so unforgettable!

Second, the Java Champions program continues to flourish. This year, in 2023, we welcomed 18 new members whose voices add to the harmony of fellow Java Champions. So to the newest members and to all Java Champions: Thank you for keeping burning bright the Java light.

Also, the community has participated in many ways and we've tried to acknowledge their experiences and voices through the Duke's Corner Podcast. This year, 8 members of the Java community, shared their unique knowledge and experiences to all! So, have a listen, and hopefully we can record you in a future episode.

And finally, a special thank you to all of the inaugural contributors to dev.java, the official Java portal: Venkat Subramaniam, Jeanne Boyarsky, Heinz Kabutz, Cay Horstman, Daniel Schmid, and Gail and Paul Anderson. Thank you for sharing your articles with the Java community. We're looking for more contributions from the community, so please visit us on our official GitHub page, so we can publish your contributions to the entire Java world.

In 2024, we're looking forward to seeing even more Java community participation that we can highlight at year's end. Until then, my sincerest gratitude to all of you: those of you that have contributed, those of you that continue to learn, those of you that continue to share, and those of you that continue to collaborate. Thank you for keeping Java vibrant and have a fantastic happy new year!

Gloating about YouTube

Thanks Shar!

I don't want to bore you with gloating about how cool this channel is but... you know, we spend a lot of time on it, and we can see from your reaction that it's worth it, so I'll do it anyway - gloating, I mean; and maybe boring you, too. Just gimme two minutes.

This is Inside Java Newscast #60 and it's running in its third year now and roughly tripled its viewership during that time. We had some bangers this year with "Java 21 is no LTS Version" being my absolute favorite - keep spreading the word!

Embedded video.

While Jose slacked a bit on JEP Cafes, he's been really killing it with his YouTube Short series "Cracking the Java Coding Interview", getting over 850.000 views this year and about as many thankful comments on them. And Billy keeps digging into JDK internals with both his Sips as well as the new Stack Walker videos that take a bit more time to dive deeper. I link my favorite one in the description.

But we're not just all doing our own thing, we also occasionally work together. Leading up to the JDK 21 release, we published the RoadTo21 video series which was a lot of fun and very well received, so I'm sure we'll repeat that for JDK 25 in 2025. And in September we had a big Java 21 launch stream, with Ana taking first place for most hours moderated. We enjoyed that a lot as well and will probably do it again for 22, albeit maybe a bit shorter than 8 hours.

All that was watched for a total of over 130.000 hours and more than 30.000 of you decided it was worth a subscription which brings us within a hair's breadth of surpassing the 150k subscriber threshold. That's so cool, thank you very much for that.

Instead of asking you to do all the YouTube things today, I want to close with thanking you all very, very much for subscribing, watching, and commenting; but beyond that for being active members of the various online Java communities, be it on Reddit, Twitter, or Mastodon (and Bluesky, we're getting there); or for participating in local Java User Groups, for visiting or speaking at conferences, for maintaining open source projects, and just generally for being members of this amazing community. I can't describe how proud I am to be a part of it. Have a great last week of the year and I'll see you again in 2024. So long...

Watch the video.

How Project Valhalla And JSpecify Can Kill NPEs

Nicolai Parlog — Thu, 14 Dec 2023 00:00:00 GMT

Project Valhalla's value types need to be aware of which instance can be null and which can't, so the JVM can inline them. So will Java get a null-aware type system after all? Not quite, but it may get close and JSpecify can help with some of those steps.

Hey, I'm nipafx, but you can call me Nicolai and today it's gonna be you, me, Kevin Bourrillion, and Project Valhalla, specifically its interest in and intentions for null. As I'll explain in a minute, Valhalla needs to know which value type instances can be null and which can't, so it can inline them. There have been different ideas for how to do that, but the most recent one proposes to introduce question mark and exclamation mark, or bang, as modifiers for value types. Then, for example, an Integer! could be treated as an int and we'd get similarly performant behavior for non-null instances of our own value types.

Now, tracking null is also something that IDEs and tools can do for you, but they're not quite aligned on how they do that and there are various discrepancies. A standard is needed and together with other people, Kevin is working on that in JSpecify. A few months ago, he presented it on my Twitch channel and I uploaded most of his presentation earlier this week - give it a watch if you want to know the goal, design, and progress of JSpecify.

In that video, I left out the section of his presentation that revolved around the overlap between JSpecify and Valhalla as well as our conversation about that topic, for example how JSpecify could help with a hypothetical expansion of question mark and bang to reference types. This video here are those parts stitched together, but I took the freedom to rearrange them for a better structure, so please forgive the occasional dangling pointer to something that's missing or comes later. So, here it is: Java, null, JSpecifcy, and Project Valhalla. Enjoy!

You might have noticed on the screen behind me that I had a second guest on. That was Manu Sridharan of NullAway fame. He's one of the other contributors to JSpecify and he had more to say on non-Valhalla topics in the Q&A after Kevin's presentation, where I and the stream audience got to ask all kinds of questions about JSpecify. I hope to upload that next week, but it's quite a bit of work. I think a few likes on this video could really motivate me to spend my weekend on that. So long ...

Watch the video.

Java, null, and JSpecify

Nicolai Parlog — Mon, 11 Dec 2023 00:00:00 GMT

Kevin Bourrillion gives an introductory presentation on JSpecify, a project spearheading a set of standard annotations for Java static analysis, specifically for tracking null

Hey, I'm nipafx, but you can call me Nicolai and today it's gonna be you, Kevin Bourrillion, and JSpecify. This is from a live stream on my Twitch channel a few months ago and while I was there, too, and so was Manu Sridharan, this video contains just Kevin's presentation about JSpecify, a project spearheading a set of standard annotations for Java static analysis, specifically for tracking null. After Kevin gave us a great overview, we had a detailed conversation about the project, including an illuminating exchange on Project Valhalla and why it cares about null, but to keep this video short-ish and sweet I'll upload that separately, hopefully before the year ends. This video is just the introduction to JSpecify. Enjoy!

And wouldn't you like to know?! I'll upload the answer to that as well as to the audience questions and the rest of the conversation soon. You may also have spotted that we skipped section 3 of Kevin's presentation. That was the part on Project Valhalla and I will upload that as well as our conversation about it in a third video. If you're watching this in the future, they may already be out and appear next to me. Otherwise, subscribe, so you don't miss them. So long...

Watch the video.

Java 22 Unpacking - Inside Java Newscast #59

Nicolai Parlog — Thu, 07 Dec 2023 00:00:00 GMT

JDK 22 will be released on March 19th 2024 but it's forked today (Dec 7th 2023) and so its feature set is final. Unnamed patterns and variables, the FFM API, and multi-source-file programs are the highlights but there is so much more. Let's unpack!

It's Christmas time, at least where I'm living, but Santa came early and already delivered us a big bag of brand new and improved Java features for JDK 22: statements before this and super, multi-source-file programs, G1 region pinning, FFM API, stream gatherers, and a bunch more. So let's unpack, shall we?

Intro

Says the script I wrote a few days ago, but things may have changed since then. You may remember that I had to do a whole second episode on JDK 21 half a year ago to cover last-minute additions and removals. So please check the pinned comments after watching this video - it will let you know whether anything changed. Down there in the description box, you'll also find links to the many videos and articles I'll mention later. And why not leave a like while you're at it? It really helps getting this video to more Java developers.

Ok, enough preamble, we'll start with the features that are set in stone and that you can use to your heart's content to improve your projects. Let's dive right in!

Final Features

Unnamed Patterns And Variables

We've looked into unnamed patterns and variables in detail in Inside Java Newscast #46. The TL;DR is that you can use the single underscore to mark variables that you do not intend to use. With local variables...

int _  = sumGearRatios(input);

pattern variables...

if (obj instanceof
		Circle(Point _, int radius)) {
	// ...
}

resources in try-with-resources blocks...

try (var _ = ScopedContext.acquire()) {
    // ...
}

for loops...

for (int _ = 0; ; ) {
	// ...
}

caught exceptions...

try {
	// ...
} catch (IOException _) {
	// ...
}

and lambda parameters you can replace the variable name with the underscore.

int someLargeNumber = numbers
	.reduce((_, num)
		-> num > MAX_VALUE/2 ? num : 0);

In patterns, you can go one step further and elide the type of an unnamed variable as well. So, to create a Function<Integer, String>, for example, that ignores the input, you can write a lambda Integer _ -> "foo", var _ -> "foo", or just _ -> "foo". Whichever variant you choose, you can never reference such variables, so there can't be any collisions and so you can have as many underscores in the same scope as you want.

Unnamed variables are particularly important when switching over a sealed type. Such a switch needs to be exhaustive, meaning it must cover all possible types, but it should avoid a default branch or permitting new subtypes doesn't lead to the desired compile error. Without a default branch, expressing the same "defaulty" behavior for a few different types is cumbersome, though, because branches like case Circle c and case Rectangle r cannot be combined - if they could, neither c nor r could be used because you'd never know whether the shape is a circle or a rectangle.

switch (shape) {
	case Triangle t -> highlight(t);
	case Circle c -> { /* ... */ }
	case Rectangle r -> { /* ... */ }
}

switch (shape) {
	case Triangle t -> highlight(t);
	// compile error
	case Circle c, Rectangle r -> { /* ... */ }
}

With unnamed variables, the situation is different: You cannot reference them anyway, so it doesn't matter which type the variable actually has and so case Circle _, Rectangle _ works and you can thus express defaulty behavior ~~with a default branch~~, sorry, without a default branch - that's the important part. This is the way to go and that's why unnamed variables are more than a nice-to-have feature.

switch (shape) {
	case Triangle t -> highlight(t);
	// compiles! 🥳
	case Circle _, Rectangle _ -> { /* ... */ }
}

Unnamed patterns and variables have previewed in JDK 21 and JDK 22 finalizes them without changes.

Embedded video.

G1 Region Pinning

The G1 garbage collector divides the heap into regions and treats every region separately during collections. Depending on the kind of collection and the state of the region, different things can happen, but generally speaking, objects in a region may be moved elsewhere. For objects that only the JVM uses, that's fine - it will find them in their new locations. But that's not the case for native code like C or C++ that gets called from Java. If the data it references gets moved around, terrible things will happen.

To prevent that, Java code can mark objects that it passes to native code as critical and then it's up to the garbage collector to leave them in place. A simple way to make sure they're not moved is to just not collect any garbage while any critical object is held and that's what G1 has been doing until JDK 21. To quote JEP 423:

This has a significant impact on latency: [...] In the worst cases users report critical sections [that are sections of code that hold critical objects] blocking their entire application for minutes, unnecessary out-of-memory conditions due to thread starvation, and even premature VM shutdowns .

Thanks to that JEP, the impact on latency is much lower on JDK 22. G1 will now collect garbage even while critical objects are held, but avoid the regions tht contain them.

It's good that G1 will perform better when Java passes on-heap objects to native code, but of course there's another option: Move such data off-heap, which brings us to the foreign function and memory API.

Foreign Function & Memory API

At this point, so much has been said about the foreign function and memory API, or FFM for short, that I will spare you anything but the briefest of summaries, which is: FFM allows you to interact with native code and to manage off-heap memory and it does both of that much better than the Java Native Interface and ByteBuffer, respectively. For more details, check out these links:

You'll find them all in the description.

FFM is Project Panama's crowning jewel and has been in the works for years now with the first bits and pieces showing up in incubation in JDK 14 and its first complete preview in JDK 19. JEP 454 finally finalizes it in JDK 22 with only minor changes over JDK 21.

Multi-Source-File Programs

Since Java 11 you can take a .java file and instead of compiling it and then running the resulting class file, throw it directly at the Java launcher: java Prog.java will compile it in memory and then run Prog's main method. So far this feature has been limited to single-source-file programs, meaning that if Prog.java references another source file, say Helper.java, the class wouldn't compile and hence no code would be executed.

// in Prog.java
public class Prog {

	public static void main(String[] args) {
		var greeting = Helper.parse(args);
		System.out.println("Hello, " + greeting);
	}

}

// in Helper.java
public class Helper {

	public static String parse(String[] args) {
		return args.length == 0
			? "World"
			: args[0];
	}

}

# on command line
$ java Prog.java
> Prog.java:4: error: cannot find symbol
>             var greeting = Helper.parse(args);
>                            ^

That changes in JDK 22 with JEP 458. The launch command will stay the same, but now the launcher will look up files that are referenced in the initial source file, for example Helper.java if Prog.java references it. That means when a new developer who's still learning the ropes or a more experienced developer who's experimenting or really anybody who just just throws together some code wants to go from a single source file to splitting up their code into several files, there's no hold-up. They, or we, can keep coding in this simple environment that requires no series of terminal commands, no build tool, no IDE.

# on command line with JDK 22
$ java Prog.java
> Hello, World
$ java Prog.java Java_22
> Hello, Java_22

I'm super thrilled about this and there are quite a few details to explore. We'll do that in an upcoming Inside Java Newscast - take a second to subscribe if you don't want to miss it. And this isn't even the only on-ramp feature in JDK 22! Let's take a look at the other one, but for that we have to go into preview features.

Previews And Incubations

Next up are previews and the seemingly never-ending incubation of the vector API. You need a few command-line flags to experiment with these features - I put a link in the description that explains which ones.

Simpler Main

A simpler main method that doesn't need to be static nor have a String[] args parameter, nor even be in a class - yes, a top-level method in a Java source file - first previewed in JDK 21 and we've examined it closely in Inside Java Newscast #49.

// this is the complete source
// file, i.e. there's no class

String audience = "World";

void main() {
	System.out.println(
		createGreeting());
}

String createGreeting() {
	return "Hello, Simple Main!";
}

Based on feedback, JEP 463 evolved how this feature is embedded in the specification and in the JDK implementation and the name evolved from Unnamed Classes and Instance Main Methods to Implicitly Declared Classes and Instance Main Methods. These changes under the hood require a second preview in JDK 22 but all practical aspects remain unchanged. This together with single and now multi-source-file programs. chef's kiss

Embedded video.

String Templates

String templates see their second preview in JDK 22. They are practically unchanged since their first preview in 21 and so Ana's in-depth presentation in Inside Java Newscast #47 is still the best way to learn about them.

Here, I'll leave you with this beauty, which lets you print to System.out with just PRINT."$string":

public static final StringTemplate.Processor<Void, RuntimeException> PRINT = template -> {
	System.out.println(STR.process(template));
	return null;
};

One character less than even Python, which I hear is a very important metric for some folks. Oh wait, I forgot the static import. Nevermind, then, but still cool.

Embedded video.

Vector API

The vector API is still waiting for value types to roll around. Until then, it will keep incubating with the occasional improvement: In JDK 22, its seventh incubation, btw, it can now access heap MemorySegments that are backed by an array of any primitive type, not just of byte.

Statements Before `this(...)` And `super(...)`

You know how in a constructor that must call a superclass constructor with super(...) or wants to delegate to a constructor in the same class with this(...), the explicit constructor invocation, meaning the super(...) or this(...) call, must be the first statement? That limitation is gone! Previewing for the first time in JDK 22, JEP 447 introduces the so-called prologue: statements before the explicit constructor invocation.

The statements in the prologue run in a new pre-construction context, which is strictly weaker than a static context. That just means that you can do everything in a prologue that you could do in, for example, a static method and even a bit more.

So if you want to validate arguments before delegating to another constructor or process them to create new arguments that you then pass on, you can now do that! Neat!

I'll go into more detail on this in an upcoming Inside Java Newscast, probably next year - you know what to do.

Class-File API

JEP 457 introduces Java's own bytecode parsing, generating, and manipulating API. It has a data-oriented design that pivots on an immutable representation of a class' bytecode with sealed interfaces and records and an API that allows tree traversal and streaming to read and generate bytecode.

The class-file API is intended to replace ASM as the de-facto standard to manipulate bytecode, so that ASM is removed as an upgrade blocker and updates, for example from Java 25 to 29, become easier. If that chain of statements escalated too quickly and you want to better understand how this API will lead us into a brighter future, check out Inside Java Newscast #56, and if you want to learn how it works, remind Jose the next time you see him that he should make a JEP Cafe about it.

Embedded video.

Structured Concurrency and Scoped Values

The structured concurrency and scoped value APIs are seeing their second preview in JDK 22 and are both unchanged compared to JDK 21. If you have a code base that already uses virtual threads, I highly recommend you check them out. Take a look at JEP Cafes 13 and 16 to learn how to use structured concurrency and scoped values, respectively, and give it a go. And if you want to contribute back to OpenJDK, a great way to do that is to report your experience, positive or negative, to the Loom mailing list - link in the description.

Stream Gatherers

I love using the stream API. In fact, I'm doing Advent of Code this year, and so far each of my solutions has a stream pipeline as an integral part. But when using the API a lot, you start missing operations - I'm sure this has happened to you. JEP 461 mostly fixes this by introducing the gatherer API, which previews in JDK 22.

Gatherers are to intermediate operations what collectors are to terminal operations: a general construct that allows you to implement your logic within the stream pipeline. And, like collectors, you will usually call a static method to get an implementation of the new interface Gatherer and pass that to the new gather method on Stream.

A gatherer consists of four operations:

the Initializer, which creates an initial state, should you need that
the Integrator, which consumes stream elements and emits them to the next stage and optionally updates the state
the Finisher, which gets called when there are no more stream elements to consume and can operate on the final state to emit a few more elements
and the Combiner, which is needed in parallel streams to combine two states into one

With that you can implement operations like runningAverage, fixedGroups, slidingWindow increasingSequences, and more. Check out episode #57 for the theory and this video for practice.

Embedded video.

Outro

And that's it for JDK 22. Do you have a favorite feature? I do but it was really hard to pick. I'll explain why in the pinned comment. Don't forget to check that out and to like and subscribe and I'll see you again in two weeks - so long...

Watch the video.

Java On The GPU - Inside Java Newscast #58

Nicolai Parlog — Thu, 16 Nov 2023 00:00:00 GMT

Babylon is OpenJDK's newest big project, aimed at easing execution of Java code on the GPU, which will unlock machine learning and artificial intelligence on the JVM. Here's all about its background, prototypes, and plans.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about how we can get a function like "4x * (y - sin(xy))" to be executed on the GPU, your graphics card's processing unit. Or in a distributed cluster. Or as part of a LINQ-like mechanism in Java. Or how Java code can differentiate it. But mostly, the graphics card aspect because executing Java code on the GPU unlocks the whole world of machine learning.

static double f(double x, double y) {
	return 4.0d * x * (y - Math.sin(x * y));
}

Ready? Then let's dive right in!

Sisyphus in Babylon

So what are we really talking about here? Big picture: I want to express some query or computational logic, like the function I mentioned, in my Java code and then pass it to some library, which needs to analyze the expression and check whether it makes sense in its domain. If so, it translates the expression and processes it in its environment, for example by sending it to the GPU for execution.

So the first step is for me to express the computational logic. The most natural way to do that would be to write a Java method but what artifacts can a library get out of that?

the Java source code itself
its representation as an abstract syntax tree, an AST, during compilation
the bytecode generated by the compiler
a method handle or java.lang.reflect.Method instance at run time

The problem is that none of these are good artifacts to analyze or translate the logic:

to work with Java source code, you need to build half a compiler
to get to the AST, you (again) need your own compiler or break into javac internals and deal with the fact that the AST is somewhat idiosyncratic and contains artifacts of the Java language that complicate your work here
bytecode is a low-level instruction set that almost always requires uplifting into a less detailed level of abstraction
reflection, on the other hand, is too abstract: it knows modules, packages, classes, and methods, but it stops there - it has no understanding of or access to what's going on inside a method

Because of these limitations, projects in this space have to do a lot of heavy lifting. Take TornadoVM as an example: To understand and translate Java code to GPU kernels, it uses an entire compiler, the Graal JIT to be precise, to access and further process its intermediate representation of the code. Other such projects resort to expressing the logic in strings or by building data structures that represent computations.

// hypothetical API that allows creation of data structures
// that describe a computation - here: 4x(y-sin(xy))
var fModel = func("f", methodType(double.class, double.class, double.class))
	.body(entry -> {
		var x = entry.parameters().get(0);
		var y = entry.parameters().get(1);

		var r = entry.op(mul(
			entry.op(constant(DOUBLE, 4.0)),
			entry.op(mul(
				x,
				entry.op(add(
					y,
					entry.op(neg(
						entry.op(call(MATH_SIN,
							entry.op(mul(
								x,
								y))))))))))));
		entry.op(_return(r));
	});

These approaches work, but they're far from optimal. Imagine instead a solution that lets you write straight-up Java code and pass it as a lambda or method reference. This solution would then work directly with this lambda, to interpret it as a GPU kernel, a partial SQL command or a LINQ-like expression, as a mathematical function, or as a computational recipe to be executed in a distributed cluster.

But how could Java support all these concepts and languages? Going one by one and baking them directly into the Java Language Specification would not only be a Sisyphean task due to the sheer number of possible languages and the effort it takes to evolve the Java specification and implementation, it would also lead to a truly Babylonian confusion with various, potentially conflicting code models in the same language.

What if, instead, Java gained a mechanism that allowed libraries to implement the support themselves. Not only would that keep a lot of complexity out of the specification and runtime, it would also unlock the power of Java's ecosystem to provide innovation through competing solutions for common problems as well as niche solutions for niche problems that would never have made it into the spec anyway.

And this is exactly what the brand new Project Babylon sets out to accomplish. Its main thrust is code reflection. Another important exploration is the so-called Heterogeneous Accelerator Toolkit (HAT) for GPU computation. Let's have a look at both.

Code Reflection

In early August Paul Sandoz, Library Architect at Oracle, presented on this topic at the JVM Language Summit. In fact, most of what I've said so far is just a summary of that talk that I highly recommend you check out if you have a deeper interest in this topic. In that talk, he presented the concept of code reflection, which is an enhancement of Java reflection as we know it today.

Programmers would identify an area of source code, maybe by annotating a method or by passing it as a lambda or method reference, for which Java would then build a so-called code model that can be accessed at compile time and at run time. The code model describes the Java program in a symbolic form down to individual variable declarations, method calls, arithmetic operations, etc. It's a detailed description of that program, much like bytecode but instead of being designed and optimized for execution by the JVM, it targets libraries that need to access, analyze, and transform a Java program and has APIs that allow just that.

An interesting aspect that Paul pointed out is that there's no one level of abstraction that suits all use cases. Instead he envisages an interval of abstraction within which the code model can be lowered and lifted. That would allow libraries to implement a wide variety of language integrations based on Java, from math to machine learning to LINQ...

Babylon: "I think we can do better than LINQ"

... ok, maybe even better than LINQ. But, importantly, also GPGPU, general purpose computing on a GPU. Let's have a look!

Heterogeneous Accelerator Toolkit (HAT)

The term GPGPU describes computation on a graphical processing unit that is not intended to produce an image but to perform general computation that would classically be assigned to the CPU. Why would you do that? Well, the GPU in the PC recording this, for example, has over 4,000 cores - if done right, GPGPU can lead to ridiculous speedups. And there are a number of projects enabling Java code to offload computation that way, for example Aparapi and the aforementioned TornadoVM. One of the Aparapi veterans is Oracle's Gary Frost who started putting code reflection into practice to build HAT, the Heterogeneous Accelerator Toolkit - and he presented his results at that same JVMLS.

HAT requires all data that goes to or comes from the GPU to be stored off-heap because that makes things easier and faster, for example by allowing the GPU to allocate data directly. It uses Project Panama's foreign function and memory API to handle off-heap data without a headache. And thanks to FFM's support for mapping complex objects, there's no need to slice them into primitive array - HAT can use FFM to map complex objects to, for example, C99 data layouts that the GPU can use directly.

As for the code that needs to be executed, HAT relies on code reflection to interpret it. So developers can write somewhat normal Java code - "somewhat normal" because there are still stark differences between the JVM and GPUs, for example only one of them knows what an exception is while the other has a multi-tier memory hierarchy. So somewhat normal Java code on one side and after translation through code reflection and the new class-file API GPU-architecture specific code on the other side.

There's already a prototype that does this and its performance looks pretty good. I'm not in this space, so I can't really judge the details but for facial recognition, on Gary's laptop no less, the OpenCL-code HAT produced performed 10 times faster than the parallel code written in Java, which was already about 7 times faster than the sequential implementation. That's pretty impressive to me but I'm sure there's much, much more to gain once vendors get their hands on this and start creating optimized translations.

Ubi Es & Quo Vadis

So where are we on this project? Since JVMLS in early August, Project Babylon was founded with Paul Sandoz as its lead, so it's still early days. But he's already planning to release the code reflection prototype in the coming weeks and HAT might be bundled with it. While the plan for code reflection is to evolve, stabilize, and eventually release as part of OpenJDK, HAT has a different trajectory.

Instead of baking one GPGPU API into the JDK, HAT is planned to stand as one of many outside libraries that allow Java on the GPU. As part of that, its next steps are to work with GPU vendors to agree on common sets of data types for the API to define. As for the backend-specific implementations, for example for CUDA or OpenCL, the goal is to have the respective vendors implement theirs.

If you want to learn more about all of this, watch the JVMLS presentations by Paul Sandoz about code reflection (slides), Gary Frost about HAT, and while you're there, Juan Fumero's about TornadoVM - all three are super interesting. They're linked in the description or you can check out all JVMLS videos in this playlist. Don't forget to like and share the video, so more Java developers get to see it and subscribe, so I'll you again in two weeks. So long...

Watch the video.

Implementing New Java Stream Operations

Nicolai Parlog — Thu, 02 Nov 2023 00:00:00 GMT

Implementing a bunch of Gatherers to better understand the proposed addition to the stream API

JEP 461 proposes Stream::gather and Gatherer - a new intermediate meta-operation that can be used to implement all kinds of specific operations, from existing ones like map and sorted to new ones like flatMapIf and increasingSequence. Once you grokked the theory, it's time to put it into practice to implement more operations:

Watch the video.

Better Java Streams with Gatherers - Inside Java Newscast #57

Nicolai Parlog — Thu, 02 Nov 2023 00:00:00 GMT

Stream::gather is a new intermediate meta-operation that allows the JDK and us to implement all kinds of intermediate operations as Gatherers without overloading the Stream interface

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and while I'm notoriously excited about every new Java feature, I'm particularly thrilled about this one. Most of us have been using the stream API for almost a decade now and while it works great, there are quite a few intermediate operations that I miss day to day: Windowing, folding, subsequencing.

So what's the news? We're gonna get all those operations? "Yes" and "no". Or rather, "no, but yes".

Let me explain: JDK Enhancement Proposal 461 proposes an intermediate meta-operation that allows the JDK and us to implement all kinds of intermediate operations without directly overloading the Stream interface. This new API is to intermediate operations what collectors are to terminal operations and the name is similar, too: We're talking about "gatherers". Let's dive right in!

Gatherer

Terminology

A Gatherer consists of four functions and we'll go through them one by one with some examples to see what their tasks are. But before we start, let's quickly rehash some terminology:

A stream pipeline starts with a source (like calling stream() on a list), followed by a number of intermediate operations (those are the methods that return a Stream), and finally a terminal operation (like toList or the more general collect). Source, intermediate, terminal operations - they are all stages in such a stream pipeline and the elements that come from the source are transformed, filtered etc. from one stage to the next.

Now, JEP 461 proposes to add a new intermediate operation gather that accepts a Gatherer and returns a transformed Stream. Let's talk about the four functions that make it work.

Integrator

We start with the Integrator. This is the main function that consumes and emits elements. Its input is a state, more on that in a minute, an element from the previous stream stage, and an instance of type Downstream that can be used to emit elements to the next stage. Its boolean return value signals whether it wants to process more elements after the current one.

The simplest possible integrator does nothing and just passes each element on. To do that, on each call, it takes the element that's passed to it, calls downstream::push with it, and then returns true to signal that more elements can be processed.

public static <T> Gatherer<T, ?, T> doNothing() {
	Integrator<Void, T, T> integrator =
		(_, element, downstream) -> {
			downstream.push(element);
			return true;
		};
	return Gatherer.of(integrator);
}

Other simple intermediate operations are map and filter, which we can reimplement as gatherers. The integrator for a map takes the input element, applies the mapping function and passes the new element downstream.

public static <T, R> Gatherer<T, ?, R> map(
		Function<? super  T, ? extends R> mapper) {
	Integrator<Void, T, R> integrator =
		(_, element, downstream) -> {
			R newElement = mapper.apply(element);
			downstream.push(newElement);
			return true;
		};
	return Gatherer.of(integrator);
}

The integrator for a filter takes the input element, applies the predicate and, if it returns true, passes the element on - otherwise it does nothing with it.

public static <T> Gatherer<T, ?, T> filter(
		Predicate<? super  T> filter) {
	Integrator<Void, T, T> integrator =
		(_, element, downstream) -> {
			var passOn = filter.test(element);
			if (passOn)
				downstream.push(element);
			return true;
		};
	return Gatherer.of(integrator);
}

Both integrators always return true because they'll never stop processing elements.

Now let's do something more interesting and implement a stateful operation.

Initializer

A stateful operation is one that creates and updates state - shocking, I know. These two aspects, creation and updates, are executed by two different functions.

Creation is the task of the initializer, which is just a fancy name for a Supplier. It is called before the first element is processed to create the initial state instance.
State updates happen during integration. Remember a minute ago when I said that a state is passed to the Integrator? That happens, so it can read and potentially mutate it.

Let's reimplement the stream operation limit with that. It needs to keep track of how many elements it has already seen, so we'll need a mutable counter. AtomicInteger fits the bill. So our initializer returns a new instance of AtomicInteger, starting with value 0. The stream API will then pass that instance to our integrator, which gets the integer, interpreting it as the current element's index, before incrementing it. A simple comparison of that index with the integer passed to our limit informs our integrator whether it wants to pass the element on. Done. Or are we?

public static <T> Gatherer<T, ?, T> limit(int numberOfElements) {
	Supplier<AtomicInteger> initializer = AtomicInteger::new;
	Integrator<AtomicInteger, T, T> integrator =
		(state, element, downstream) -> {
			var currentIndex = state.getAndIncrement();
			if (currentIndex < numberOfElements)
				downstream.push(element);
			// ...
		};
	return Gatherer.ofSequential(initializer, integrator);
}

What should the integrator return? If it's always true, it will consume the entire stream. That's technically correct but wasteful for finite streams and a big problem for infinite stream. So this is the first example where the integrator returns false, namely when the next element would be beyond the limit.

public static <T> Gatherer<T, ?, T> limit(int numberOfElements) {
	Supplier<AtomicInteger> initializer = AtomicInteger::new;
	Integrator<AtomicInteger, T, T> integrator =
		(state, element, downstream) -> {
			var currentIndex = state.getAndIncrement();
			if (currentIndex < numberOfElements)
				downstream.push(element);
			return currentIndex + 1 < numberOfElements;
		};
	return Gatherer.ofSequential(initializer, integrator);
}

Another stateful operation, and arguably a cooler one, only emits elements that are larger (by a given Comparator) than all the elements seen previously. This transforms a sequence into an increasing subsequence, so for example "1, 3, 2, 5, 1" gets turned into "1, 3, 5". To implement this, the initializer returns an empty AtomicReference as initial state. The integrator then uses the comparator to figure out whether the current element is larger than the one in the state and, if so, emits it and writes it to the state object. Otherwise, it ignores it. And it always returns true to continue processing the stream because you never know whether a later element won't be larger.

public static <T> Gatherer<T, ?, T> increasing(
		Comparator<T> comparator) {
	Supplier<AtomicReference<T>> initializer = AtomicReference::new;
	Integrator<AtomicReference<T>, T, T> integrator =
		(state, element, downstream) -> {
			T largest = state.get();
			var isLarger = largest == null
				|| comparator.compare(element, largest) > 0;
			if (isLarger) {
				downstream.push(element);
				state.set(element);
			}
			return true;
		};
	return Gatherer.ofSequential(initializer, integrator);
}

But what if we need to do something after the last element? Some kind of final operation? That's where the third function, the ~~finalizer~~ finisher comes in.

Finisher (not Finalizer!)

After our gatherer is done integrating, it will get one final chance to emit elements. To that end, the state and downstream are passed to the ~~finalizer~~ finisher function, which can emit more elements as it sees fit.

One example operation where this comes in real handy is a grouping function that transforms a stream of elements into a stream of groups of elements. In such cases you usually only emit a group once it's completed but, when you're processing the stream's last element, you don't know that you need to complete the current group. And if you don't, the last group is missing.

A simple example of this is an operation that emits groups of fixed size, which is given as a parameter: The initializer creates an empty array list as state and the integrator adds the element to the list and, if it reached the desired size, emits a copy of it before clearing the list. You can see how this can leave the last group hanging if the last element didn't happen to complete it. So our ~~finalizer~~ finisher just takes that list and, if it's not empty, emits it, to make sure that the last couple of elements show up in a group in the downstream stage.

public static <T> Gatherer<T, ?, List<T>> fixedGroups(int size) {
	Supplier<List<T>> initializer = ArrayList::new;
	Integrator<List<T>, T, List<T>> integrator =
		(state, element, downstream) -> {
			state.add(element);
			if (state.size() == size) {
				var group = List.copyOf(state);
				downstream.push(group);
				state.clear();
			}
			return true;
		};
	BiConsumer<List<T>, Downstream<? super List<T>>> finisher =
		(state, downstream) -> {
			var group = List.copyOf(state);
			downstream.push(group);
		};
	return Gatherer.ofSequential(initializer, integrator, finisher);
}

A more interesting example would be to turn our increasing subsequence operation into one that emits portions of the original sequence that are increasing, so "1, 3, 2, 5, 1" gets turned into "[1, 3], [2, 5], [1]". I'll leave that as an exercise to you. Or, if you're lazy, check out the video I published on my private channel where I implement all Gatherer examples given here and a few more.

Embedded video.

Combiner

The last of the four operations is the combiner. It's only needed for parallel streams, but would you look at that!, it's already way past bedtime for me, so I'll leave this non-trivial topic to the eventual JEP Cafe.

Gatherers

So JEP 461 proposes Stream::gather, the Gatherer interface, and a few more types that needs. It is not currently targeted to any release, but I hope that it previews in 2024, ideally in JDK 22.

Once the feature is final, we get the capability to express all kinds of intermediate operations by implementing them as a Gatherer and passing it to Stream::gather. The easiest way to share them is to add the factory methods that create them to some utility class. In fact, that's exactly what JEP 461 proposes because it also comes with a Gatherers class (plural; again, much like Collectors) that contains operations like folding, scanning, sliding windows, and a concurrent map that spawns a virtual thread for each application of the mapping function. Check out more about all that in the JEP that is of course linked in the description.

Oracle VS Code Extension

One more thing before I let you go: If you're using Visual Studio Code / VS Code, whether as a new Java developer, for experiments with new Java features, or for work on regular projects, you should absolutely try out the new Oracle Java extension. It has a few cool perks over the default Java extension:

it's based on javac for earlier support of new version, like 21 right now and soon 22-EA
it has better Gradle integration
and has overall a much smoother development experience

I'll leave a few links related to the extension in the description, right under the like button. Which, you know, you could press if you check them out. That helps the channel and let's more Java developers know about gatherers, which spares you from having to explain it to them. Win, win! Also, subscribe, and I'll see you again in two weeks. So long...

Watch the video.

Java Architects Answer Your Java Questions

Nicolai Parlog — Thu, 26 Oct 2023 00:00:00 GMT

Try/catch expressions? Valhalla timeline? Synchronizing virtual threads? And many more. Here's how Brian Goetz, Alan Bateman, Stuart Marks, and Kevin Rushforth answered your questions.

Part 1

I did not expect that! A few weeks ago I invited you to ask me anything about Java and my plan was to take a dozen or so questions to Devoxx Belgium, have them answered by my dear colleagues in Oracle's Java Platform Group, and put them into a neat little Inside Java Newscast that comes out on October 19th.

Well... Across YouTube, Reddit, Mastodon, and the like, I got over 250 replies and even after picking your favorites and a bit of deft editing, I ended up with over one hour of interviews. That's not a Newscast, that's not even a good video, it's way too long.

So instead, we're doing this. Which is me, in my living room, recording a video - but it's not a Newscast! It's the first half of the AMA, in which I and, when I ran out of steam, The Cleaner himself asked Brian Goetz, Java Language Architect and Project Lead of Amber and Valhalla, questions about exactly those two projects. From if/else and try/catch expressions to named arguments and union types, from machine learning to a timeline on Valhalla, we covered a lot of ground and got a ton of good info that I'm sure you'll love to hear about. So have fun with that and, if you didn't already, make sure to subscribe, so you don't miss the second half next week, when I ask Stuart Marks, Kevin Rushforth, and Alan Bateman about math, GUIs, and virtual threads respectively- Oh, and I'll answer a few questions, too.

But now, let's see how Brian replies to your questions.

Project Amber - Brian Goetz

The getFoo() and setFoo() convention was established by the JavaBeans specification, and is widely used outside Java beans, but well known style guides including an old one by Sun and Google's newer guide don't actually insist on it. The new Record class doesn't use it, either. Does the Java team have any thoughts on naming getters and setters?
(Question & Answer)

Records are great for immutable things but that doesn't obviate the need for mutable things. Why not have the ability to define mutable records....may be with a new keyword "javabean" as in: public javabean Whatever(String a, String b);
(Question & Answer)

In which version of Java are we going to have shorter version of “System.out.println()”?
(Question & Answer)

On the "why can't we have" series I was missing if/else and try/catch as expressions. Switch alone is not sufficient.
(Question & Answer)

Are there any plans for named arguments, even for limited applications like Record constructors?
(Question & Answer)

Any (potentially far-off) plans for union types? It would be super helpful for things like Result<MyType, ErrorA | ErrorB> kind of situations, exceptions tend to get unwieldy, and defining a sealed interface for that is a bit un-ergonomic
(Question & Answer)

Are there any plans to support delegation in the language, something like : Type by prop in Kotlin? I think this would give a great incentive to use composition over inheritance, since you would suddenly save roughly the same amount of code.
(Question & Answer)

While reading the JEP it mentioned as "We are propose to finalize it without change". If there is no difference between preview and final, can next patch release of JDK 21 make the feature as final as well.
(Question & Answer)

Project Valhalla - Brian Goetz

Valhalla when
(Question & Answer)

Are there any plans for java to try and take share from the ML/AI pie?
(Question & Answer)

How to attract more interest in Java for number crunching/scientific applications? [...] Do we know if the Java architects have any interest in targeting the scientific community?
(Question & Answer)

Are there any discussions about adding a data table structure natively to Java? We live in a data world and the tabular format is an expected way to handle it (spreadsheets, matrices...)
(Question & Answer)

Do you think with Valhalla and Panama, Java could become more relevant for game development?
(Question & Answer)

Outro

And that was that. I hope you learned something new - if you did, leave a like, so more Java developers get to see this video. If you can't get enough of Brian, check out his Devoxx keynote and don't forget to subscribe, so you don't miss the second half of this AMA. So long...

Part 2

Embedded video.

Are there any plans to invest into Java on Desktop? Is work being done to make virtual threads scale better with synchronization? Is it possible to make a Java 2.0 with breaking changes in a new release? And why is MathContext so clunky?

This is the second half of the AMA where I took these and more of your questions to Devoxx Belgium to interview the experts from the Java Platform Group at Oracle. Without further ado, here are their replies.

Java UI Frameworks - Kevin Rushforth

I am hugely interested in GUIs. Java has two - Swing(Not thread-safe) and JavaFX. Which one is better? Or we need any other safe feature-rich framework for GUIs?
(Question & Answer)

Any plans to invest into Java on Desktop?
(Question & Answer)

When will Java get some media processing capability, like ability to play back videos? At least the ones with non-patent-encumbered codecs?
(Question & Answer)

When will AWT get WebP image format support? AVIF?
(Question & Answer)

Project Loom - Alan Bateman

Which are the use cases of platform threads and virtual threads? How to choose between them?
(Question & Answer)

Virtual threads at the moment suffer from the synchronized thread pinning problem. Is there currently work done to fix that in the next java releases? If yes, is there an ETA?
(Question & Answer)

When do we get control over which set of carrier threads a virtual thread may be scheduled on? Or even use a custom scheduler.
(Question & Answer)

Why developers of web frameworks(Jetty etc) are saying that they don’t want to use or adopt virtual threads and claim that they don’t improve performance while introducing more context switching?
(Question & Answer)

Lightning Round

IIRC then GraalVM including native image will be merged into OpenJDK at some time in the future. Any news on that?
(Question & Answer) Azul has CRaC. I think condensers are somewhat similar (a superset and/ or generic concept that may or may not cover something similar to Azul's CRaC). Any news on that or maybe a timeline?
(Question & Answer)

Why does Java still not support metaprogramming?
(Question & Answer)

On backwards compatibility:

As a learner, I always like stability in the technology... Java is continuously evolving with new features and additions. Can I expect stable Java versions ahead?
We're seeing some APIs removed that have been deprecated for 10+ years, and yet there's a lot of Java code in industry that is old enough to use them. What factors is Oracle weighing while trying to preserve backwards compatibility and trying to move Java forward?
Is it possible for you to make Java 2.0 and as C# make a breaking change in new release?

(Question #1, #2, #3 & Answer)

Can we see java again in cutting-edge technologies, AI, robotics, 3D engines, VR, HPC like the old times? Supporting Java platform in multiple fields would benefit the community more than introducing new syntax features.
(Question & Answer)

APIs - Stuart MArks

Why can’t I set MathContext globally for all BigDecimals? Add them everywhere is a real pain.
(Question & Answer)

Why HashSet.newHashSet instead of HashSet.forNumberOfElements?
(Answer)

Outro

And that's it for the second half of the AMA. If you didn't already, make sure to check out the first half where we interviewed Brian Goetz about Java's language development. I hope you learned something new - if you did, leave a like, so more Java developers get to see this video. So long...

Watch the video.

New Class-File API Will Make Java Updates Easier - Inside Java Newscast #56

Nicolai Parlog — Thu, 05 Oct 2023 00:00:00 GMT

How the new class-file API that Brian Goetz presented at JVMLS will greatly improve the situation around Java updates

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're going to discuss how an API that you'll never use will make your life much easier... in, like, 3 or 4 years at the earliest. For that to make sense, we need to quickly recap what bytecode is, how it's getting manipulated, why that complicates Java updates, and, finally, how the new class-file API can improve that situation. If you already know some of that, remember that you can use chapters to navigate to what's news to you.

Ready? Then let's dive right in!

Bytecode Basics

Java bytecode is the instruction set for the Java Virtual Machine, consisting of operations like creating objects and arrays, copying variable values or references between stack and registers, invoking methods, computing arithmetic operations, etc. Those .class files that the compiler generates from your Java code? They contain bytecode. And sooner or later we throw it at a Java runtime, where the class loader will load, parse, and verify it, before passing it on to the JVM, which executes it. And that's your Java code doing its thing - in a simple world, the story would end there.

But in the real world, we want more! More performance, for example. So we have the just-in-time compiler that turns bytecode into machine code. We have class-data sharing to cut down on the work the class loader has to do. More on that in this excellent Stack Walker episode. We have Graal native image that basically takes all of this and turns it into an executable. But we can ignore all these optimizations today.

What we also want more of is flexibility and this is where bytecode manipulation comes in.

Bytecode Manipulation Basics

Because bytecode can be generated, viewed, and changed every step of the way. Frameworks like Micronaut and Quarkus generate bytecode when your project gets built to avoid reflection at runtime. A tool like jdeps can parse it to analyze dependencies, many static analyzers like SpotBugs don't actually analyze source code but bytecode, and an agent may manipulate it when it's loaded into the class loader, for example to gather performance numbers like New Relic does. And even, or rather particularly, at runtime tools and frameworks go ham, like Hibernate generating proxies to redirect calls and Mockito adding behavior according to your prescription.

What all of these tools have in common is that they need to understand the bytecode they're working with. They mostly don't do that themselves, though, but rely on a set of bytecode libraries, which are dedicated to parsing, generating, and manipulating it. A big player in this space is ASM, even if often only used indirectly: Mockito, for example, uses it via ByteBuddy, Spring, on the other hand, uses it via CGLIB.

So, in other words, bytecode libraries like ASM need to understand the bytecode they're working with. Which would be no issue if bytecode never changed. But it does and that is an issue.

Migration Pains

Java is evolving and that's not limited to the language and APIs. Specifically, the bytecode evolves, too - in a backwards compatible manner of course but that doesn't preclude adding new operations or information. In fact, the bytecode version, or "level" as it is more commonly called, is encoded in each class file and currently increases with each Java release - for Java 21, that's level 65.

And because the aforementioned bytecode libraries need to understand what they're processing, they look for that number and check whether they understand that level. If they do, great! If not, they have two choices and neither is really good:

They can give up, which means the program that tasked them with working on the bytecode will very likely not be able to proceed.# You've probably seen those error stack traces.
Or they can cross their fingers and hope nothing breaks when they do their thing, which... well, you can probably tell that that's not great either.

And herein lies the problem. Imagine you have a Spring Boot app that depends on an ASM version that works up to bytecode level 65. Then you're good to go up to Java 21. But what happens when you want to move to 22 in March or to 25 in 2025? Then you need to update at least ASM, which... you can't because Spring, like many many other frameworks, shades it. So you need up update Spring Boot or in other words most of your dependencies, which... pardon my French, but that sucks! You should absolutely be able to update the Java version without having to update the rest of your dependency tree!

But at the moment, that's still what is often necessary, which is why step zero is always: update your dependencies and tools. So one ingredient in making Java updates easier is to decouple these frameworks from the bytecode level. And that's where the new API comes in.

Class-file API

At JVMLS, the Java Virtual Machine Language Summit, Brian Goetz presented the class-file API, a JDK API for reading, transforming, and generating bytecode. The talk is super interesting and I strongly recommend you watch the recording - if not for the API itself, then just to see how Brian tackled the design process.

Embedded video.

I'm not gonna go into the API here, though. If you want to learn how it works, there's a link to the JDK Enhancement Proposal in the description. Or maybe Jose will make a JEP Cafe about it. Let us know in the comments if you'd be interested in that.

Alleviating Migration Pains

What we're focusing on here is its impact on the ecosystem. Because this API has one critical advantage over ASM and the like: It's always up to date with the bytecode!

That will not remove all update considerations: Some use cases may still struggle when the API spits out bytecodes or constant pool entries or whatever that they're not aware of, but most use cases won't have a problem and so their update path is cleared.

Going back to our Spring Boot example: If Spring Boot would already use the new API instead of ASM on Java 21 (which they can't, it*s just a hypothetical), the app can update to Java 22 or 25 without updating Spring Boot because it will of course use the new version of the API, which of course works just fine with the Java 22 or 25 bytecode. So if the new API is good enough to allow frameworks like Hibernate and tools like ByteBuddy to move away from 3rd-party bytecode libraries, you won't have to update most of your dependency tree just because you want to move to a newer Java version. And that's how it should be!

Timeline

So when will this happen? At the time of recording, the JEP is not yet targeted but the JVMLS talk gave me the impression that the API is pretty mature, so I'm hoping for a preview in 2024 and hopefully a finalization by Java 25, the next version that gets long-term support. Hopefully, during that time frame, frameworks and tools could start releasing multi-release JARs that use the new API, so when you do your update rush in late 2025 for Java 25, your stack could start working with the new API. And it's the next Java update after that, either 26 in March 2026 or 29 in September 2027, when you start benefiting from it because then you have one less reason to bump anything but your Java version if that's what you want to do. So... 3 to 4 years at the earliest - Java is definitely playing the long game.

Outro

A note before we close this episode out with a fun quote from Brian: I focused exclusively on the ecosystem aspect of this API but that is not at all the only reason it was introduced. There's much more to it and the JEP and the JVMLS talk give details on that.

And that's it for today on the Inside Java Newscast. In two weeks we'll answer the questions you sent us for the AMA - subscribe and click the bell, so you don't miss that. And while you're down there, give this video a like - it really helps getting it in front of more Java developers. Thanks and so long...

Watch the video.

Java 21 Pattern Matching Tutorial

Nicolai Parlog — Sun, 17 Sep 2023 00:00:00 GMT

Java 21 is the first Java release with all essential pattern matching features finalized: sealed types, type patterns, an improved switch, records, and record patterns. This tutorial puts them all together.

Imagine we're writing an employee management tool. For our core domain types we start with an interface Employee and for now Salaried and Freelancer are all the implementations we need. The next step is to add operations:

to request and confirm signage of legal documents
to manage access to various platforms
to track completion of compliance trainings (can you tell I'm working for a large corporation?)
to issue payments
to plan project work
to schedule holidays
etc.

We quickly realize that it's probably a bad idea to place all those very disparate operations that interact with mostly separate subsystems on the same type. Imagine, Employee gobbling up all that functionality and in turn depending on most of our system! I shudder at the thought.

So we need to separate the operations from the type. We leaf through our copy of Design Patterns and land on the visitor pattern. Immediately, the shudder returns and we wonder "Isn't there a simpler way?"

And the answer is, in Java 21, there absolutely is! Just like lambda expressions turned the strategy pattern into a language feature, so we hardly think of it as design pattern anymore, does pattern matching turn the separation of types and operations into a simple application of a few language features, namely patterns, switch, and sealed types. And that's what this last episode in the road to Java 21 is all about, so let's get started!

So it should come at no surprise that this is what's called pattern matching. Pattern matching lets you construct your own data-driven dispatch in your implementation code, rather than in API code.

Ingredients

Extended `instanceof`

We'll take things slowly and start with a feature that you, if you're on Java 17, might already have used: the extended instanceof. The old, clunky way to type check with instanceof consists of three steps:

the type check
the declaration of a new variable, and
a cast of the general variable into the new one

public void pay(Employee employee) {
	if (employee instanceof Freelancer) {
		Freelancer freelancer = (Freelancer) employee;
		// use `freelancer` ...
	} else if (employee instanceof Salaried) {
		Salaried salaried = (Salaried) employee;
		// use `salaried` here
	}
}

The extended instanceof combines all three steps into just one operation. With a simple if (employee instanceof Freelancer freelancer) we get the type check, a new variable of the desired type and name, and the old variable cast into it. We can use the new variable freelancer everywhere where the condition is true, in this case in the if-branch. Now, if we want to implement an operation that accepts an Employee instance but needs to handle each type differently, we could create a series of instanceof checks that runs through all known subtypes.

public void pay(Employee employee) {
	if (employee instanceof Freelancer freelancer) {
		// use `freelancer` here
	} else if (employee instanceof Salaried salaried) {
		// use `salaried` here
	}
}

I know you're feeling that shudder again but stick with me, it's only a hypothetical step on the path to a good solution. Let's a analyze it, though.

If the method doesn't return anything, the if-else-if chain doesn't need to cover all cases and if we add an additional class Contractor implements Employee, for example, we silently get no behavior at all for its instances and that's not good. So it's probably a good idea to at least add an else branch that throws an exception but then we still only find out at run time that a branch is missing.

public void pay(Employee employee) {
	if (employee instanceof Freelancer freelancer) {
		// use `freelancer` here
	} else if (employee instanceof Salaried salaried) {
		// use `salaried` here
	} else {
		throw new IllegalArgumentException();
	}
}

That's a serious maintainability problem and the reason for the shudder you felt earlier when I started going down this road. We'll need to improve over this. But let's put a pin in it for now and turn to another feature that's already available in 17, one you've probably used way more often.

Switch enhancements

The good old switch statement has seen two important improvements. One is that we can use it as an expression, meaning it computes a value that we, for example, assign that to a variable on the left-hand side or return from a method. Where to use this depends on context: Do we need to compute a value, then we'll use switch as an expression, or do we just execute some code, then a statement is fine. The other improvement is that instead of following up the case label with a colon :, we can now use the lambda arrow ->, which eliminates fallthrough and thus the need for all those breaks. This should definitely be your default choice unless you intentionally want to fall through.

Now, imagine for a moment that instead of an Employee interface with two implementations... ... we had created an EmployeeType enum with two values SALARIED and FREELANCER. Then one way to implement an operation that differentiates by type would be to switch over employee.type() and to write a case for each enum value. We can use the fancy new arrow syntax but there doesn't seem to be a need for a switch expression and so it's a statement.

public interface Employee {

	// [...]

	EmployeeType type();

	enum EmployeeType {
		SALARIED, FREELANCER
	}

}


public void pay(Employee employee) {
	switch (employee.type()) {
		case SALARIED -> paySalary(employee);
		case FREELANCER -> payInvoice(employee);
	}
}

Unfortunately, a switch-over-enum statement doesn't need to cover all cases either and so we get the same behavior as with the if-else-if chain where a new enum value is silently ignored. We can add a default branch that at least throws an exception but we would still rely on tests to find errors before they occur in production. Still the same maintainability problem, still needs improvement.

On the way there, let's combine the two approaches. We're back to an interface with two implementations but now we're using the type check from the extended instanceof in switch - this is only possible without additional command line flags since Java 21.

public void pay(Employee employee) {
	switch (employee) {
		case Salaried salaried -> paySalary(salaried);
		case Freelancer freelancer -> payInvoice(freelancer);
		default -> throw new IllegalArgumentException();
	}
}

As you can probably tell by now, a line like case Freelancer freelancer -> something checks whether employee is an instance of Freelancer and, if so, executes the code on the right, where a variable of name freelancer and of type Freelancer is available. At first, the only advantage of this is that we have the expressiveness of the switch that clearly communicates that we have one action per branch while not needing an additional enum to differentiate by type - the class information suffices.

The game changer is hidden in between the last case and the end of the switch. See what happens when I remove the default branch:

public void pay(Employee employee) {
	// compile error:
	//     "'switch' statement does not cover
	//       all possible input values"
	switch (employee) {
		case Salaried salaried -> paySalary(salaried);
		case Freelancer freelancer -> payInvoice(freelancer);
	}
}

We get a compile error! That's because the compiler requires that a switch over a complex type covers all possible implementations. As is that only forces us to include a default branch but now we'll fold in another Java feature that you might already be using on JDK 17, although that would surprise me a bit because it didn't really get you anything.

Sealed types

And that's sealed types! Regular types can be implemented by anybody who can get a hold of them and, in the case of a class, can reach the super constructor. For simplicity's sake, let's stick to interfaces, though. The only way to limit an interface's extensibility is via the its visibility - otherwise, everybody can implement it! And that's fine for things like Collection or List but with core domain types that have a lot of logic attached to them, it's not really feasible to expect that simply adding an implementation, like a Contractor for our Employee just works and doesn't require any other changes in the system. No, your code probably depends in you knowing every implementation of that interface.

And that's what sealed interfaces are for. You can declare an interface like Employee sealed and then permit all possible implementations - in our case that's Salaried and Freelancer.

public sealed interface Employee
	permits Salaried, Freelancer {

	// [...]

}

There are some requirements for the types that implement a sealed interface or extend a sealed class but I'll gloss over that here - there's a link to a detailed explanation of sealed types in the description. What's important for us here, and really 80% of what sealed types are about, is that the compiler understands the limited extensibiliy. For a sealed interface Employee permits Salaried, Freelancer it knows that when you have an instance of Employee it must be either an instance of Salaried or of Freelancer. And with this final ingredient, we get our compile-time verification of operations that need to differentiate by types.

Put together

Because look what happens to our switch when we make Employee sealed:

public void pay(Employee employee) {
	// switch is exhaustive ~> no compile error
	switch (employee) {
		case Salaried salaried -> paySalary(salaried);
		case Freelancer freelancer -> payInvoice(freelancer);
	}
}

The compile error is gone! The compiler understands that we covered all possible subtypes of Employee, that's called "exhaustiveness" or "being exhaustive", and it stops bothering us. But at the same time it's still watching us closely. Because when we add a third implementation, we also need to add it to the permits clause and, bham, the compile error is back!

public sealed interface Employee
	permits Salaried, Freelancer, Contractor {

	// [...]

}

public void pay(Employee employee) {
	// switch is no longer exhaustive ~> compile error
	switch (employee) {
		case Salaried salaried -> paySalary(salaried);
		case Freelancer freelancer -> payInvoice(freelancer);
	}
}

This is huge! This is what the entire complexity of the visitor pattern was there for: to separate types from operations while making sure that adding a new type forces us to update all operations to handle it. This way we get the same safety - all we have to do is make the type sealed. And avoid default branches! That's important, let's talk about that for a minute.

Exhaustiveness

When switching over complex types, the compiler requires exhaustiveness. The trivial way to achieve that is to add a default branch but the critical disadvantage of that is that if we add another implementation of the sealed type, the switch is still exhaustive and we don't get a compile error and so we don't have to update our operation for the new type and it silently falls into the default branch. That may be the correct way to handle it, but it also might not be and it's really only the developer, us, who can make that decision. So it's important to avoid an outright default branch and instead list all types explicitly. We cannot combine multiple types into one branch and so, in the worst case, we may have to repeat the same behavior for a few different types. If only there was a better way to handle this.

And that, my friends, is called foreshadowing. I'm alluding to something that happens later in the video to build anticipation and add tension. So you stick around for the important things that are coming instead of switching to cat videos. Are those still a thing or am I dating myself? Anyway, before we resolve this tension, let's talk about the term in the title of this video that I didn't even explain yet: pattern matching.

Pattern matching

Remember the instanceof triad? A check, a declaration, a cast? If we generalize this to "a check, declarations, extractions", we get something much more powerful. For example:

"if the Employee is of type Freelancer declare a variable Freelancer free and assign the employee to it", or
"if the Freelancer is composed of a name and an hourly rate larger than 250 EUR, create a variable String name and assign the freelancer's name to it, because we probably wanna fire them", or
"if the List<String> is not empty, declare variables String first and List<String> tail and assign the first element of the list to first and the rest of the list to tail", or
"if the Map<Id, User> contains an entry for a specific ID, declare a variable User u and assign the user associated with that variable"

Checking a variable for some property and then declaring new variables to capture that property is extremely common. What you're doing here is matching a variable to a pattern and if it fits, extracting information according to that pattern. So it should come at no surprise that this is what's called pattern matching. The extended instanceof and its counterpart in switches are called type patterns but that's not the only pattern Java has on offer. But before we get to the other one, let's zoom out a bit. There's a bigger picture of what pattern matching means for Java and who better to explain it than Java Language Architect and player of long games Brian Goetz?

So, pattern matching is related to dynamic dispatch. And, historically, Java's approach to dynamic dispatch is tied strictly to the class hierarchy. So, we define a virtual method through an interface or a base class and then subclasses provide their own implementations, and the method invocation mechanic handles the dynamic dispatch. And this is really powerful, but it's rigid. Because in order to harness the power of this dynamic dispatch, we have to reflect the dispatch points as public API points, and reflect each dispatch option as a separate implementation of the type declaring the dispatch point.

This works great when the dynamic behavior is something that we really want as a first-class, public API point. But sometimes we want to make dynamic, data-driven decisions without having to expose all of this in our APIs.

So, historically, the way we had to do this was with the visitor pattern, and this works but it really just moves the problem somewhere else. So, visitor lets you take polymorphic operations out of the public eye/API for your domain model, but the flip side is that visitors are pretty intrusive and rigid in their own way. So, pattern matching lets you construct your own data-driven dispatch in your implementation code, rather than in API code. And this is more flexible, more concise, less intrusive, and can be used to yield benefits in several different ways.

Now, pattern matching wouldn't, and shouldn't, replace API-based polymorphism; it complements it. Some polymorphic operations are essential to the domain and they make total sense to be part of your API, and we'll continue to use public API points for these. Others don't really make sense to be part of your domain model and pattern matching lets us more easily move these to where they belong. So pattern matching gives API designers a richer toolbox for exposing the right shape API.

Now, if we were to decide that a particular polymorphic operation belongs in the API, pattern matching still offers us some extra flexibility: You can continue to use method overriding to implement the operation, but if you know all your subtypes (which is going to happen more frequently now that we have the ability to declare sealed class hierarchies), you can also write a single data-driven implementation using pattern matching. And the clients won't be able to tell the difference. So if you have pattern matching in the language, even if you're not going to use it to change the structures of your APIs, it still offers implementation flexibility for API developers.

And finally, pattern matching gives more flexibility to API clients because they can more easily and safely create new polymorphic behavior even if the underlying domain model hasn't exposed it directly.

So we should think of pattern matching as offering us another path to polymorphic dispatch, that can be used in different situations from ordinary virtual dispatch. And if the data-oriented polymorphism of pattern matching is a better fit for your problem, you can use that, and otherwise we can continue to use the tried and true object oriented techniques.

Data-oriented programming

Intro

As Brian just explained, pattern matching can be used to implement polymorphism. In an object-oriented approach, that can occasionally complement polymorphism by inheritance but we can take it much further and forego OOP for most of our domain and pick a much more functional approach. But where functional programming places functions at the center with data representation a close second, what I'm talking about switches that around, no pun intended, and focuses on data first. It's called data-oriented programming.

Data-oriented programming proposes the representation of outside data in your program not as objects that combine mutable state and operations and that data needs to be contorted to align with but instead represent it as closely as possible with simple, immutable types - we'll see in a second how to do that. You'd apply data-oriented programming in situations where a system or subsystem is mostly focused on ferrying data back and forth between a few connectors to outside systems and that doesn't require the kind of modularization object-oriented design affords us. That is more likely if the system or subsystems is somewhat small. But how do you represent data as closely as possible?

Ingredients

The ingredients are relatively simple. The main one, and if you're on JDK 17, I'm sure you've already used it, are records. Designed as transparent carriers of immutable data, they're perfect for this task. (And thats no coincidence, by the way.) You'll use them to create types that represent specific data as closely as possible so you get the most out of Java's type system.

So if your data contains salaried employees with a name and a pay grade as well as freelancers with a name and an hourly rate, don't try to find a smart way to combine that in one class. Just create two records that fit the data exactly. And put in the work to make them airtight. You want to enforce all requirements for the data in the constructor or a factory method to make sure that only legal states are represented. And by default, these types should be deeply immutable. Record fields cannot be reassigned but if they reference a mutable type, say an ArrayList, the collection could still be changed by calling add or clear - you probably want to assign a List.copyOf to the field instead.

public record Salaried(
		String name, PayGrade payGrade, List<LocalDate> holidays)
		implements Employee {

	public Salaried {
		Objects.requireNonNull(name);
		Objects.requireNonNull(payGrade);
		Objects.requireNonNull(holidays);
		holidays = List.copyOf(holidays);
	}

	public enum PayGrade {
		A, B, C
	}

}

Still, some data might have non-required fields. We can argue whether to model them with null or give their component an Optional type (I'm clearly in the latter camp, by the way) but don't let this seduce you into modeling an "A or B" scenario as a single type with tons of non-required fields.

Instead, add the other ingredient: sealed types. You'll use them whenever there are alternatives between different kinds of data. So if your data contains contracts and each contract links to an employee that is either salaried or a freelancer, you'd create a sealed interface Employee that permits two implementations Salaried and Freelancer.

Operations

That nails our types down, now let's talk about operations. Unless they just combine data on the same type, like a first name and a last name to a full name, they should not be defined on these types. Beyond that, you already know most of what you need to know about operations over these types from the first part of the video but since we're now dealing with records a lot, let's add the other kind of pattern that I alluded to earlier. That would be record patterns. Remember this example?

If the Freelancer is composed of a name and an hourly rate larger than 250 EUR, create a variable String name and assign the freelancer's name to it

That's exactly what record patterns do! The check is whether we indeed have an instance of the record, the declarations are one per component, and the extractions are assigning the component values to these variables.

With record patterns, the implementation of extracting the freelancer's hourly rate is a simple case Freelancer(String name, double hourlyRate) or (var name, var hourlyRate) if you prefer. And if we want to add a condition, we use a so-called guarded pattern. After any pattern, we can write when and then some boolean condition and of course the branch is only executed if the condition is true.

public void pay(Employee employee) {
	switch (employee) {
		case Salaried(var name, var payGrade, var holidays)
			-> paySalary(payGrade);
		case Freelancer(var name, var hourlyRate) when hourlyRate > 250
			-> payInvoice(hourlyRate);
		case Freelancer(var name, var hourlyRate)
			-> payInvoice(hourlyRate);
	}
}

The astute among you may wonder how this interacts with exhaustiveness. Clearly a case Freelancer when hourlyRate > 250 does not cover all freelancers. Can you add a case Freelancer when hourlyRate <= 250? Yes, absolutely, but it won't do what you hoped - the compile error would still be there. The reason is... well, that Computer Science is very mean: If you allow arbitrary checks after a when, it is categorically impossible that the compiler can figure out for all conditions whether all possibilities are covered. You could limit the kind of conditions and then implement a checker for that and then make all that part of the Java specification, set in stone for eternity.

Or you just don't, treat any guarded pattern as inherently incomplete, and require an unguarded pattern for each type to achieve exhaustiveness. So, in this case, just add a case Freelancer without any when after all the case Freelancer when and the compiler is happy. Yes, you don't get to express the symmetry of larger than vs smaller than or equal to but unless you're like me, you're probably not gonna loose sleep over that.

Principles

If you want to learn more about data-oriented programming, watch Inside Java Newscast #29 or read Brian's seminal article on the topic, both linked in the description. For now, I want to leave you with the four principles he defined:

Model the data, the whole data, and nothing but the data - that's the part about creating types that match the shape and alternatives of the data closely as well as the part where you do not add operations as methods to the data but as functions operating on them.
Data is immutable - that were the records and the immutable copies in the constructor.
Validate at the boundary.
Make illegal states unrepresentable - both of which are covered by designing types correctly and rejecting illegal combinations of data in the constructor.

And that's it for data-oriented programming...

Ah right, phew, that was close! You don't want to know what happens to YouTubers who foreshadow something but then don't follow up on it. I left you hanging on how to combine multiple types into one branch with defaulty behavior.

Unnamed patterns

Hello, my name is Angelos Bimpoudis and I work for the Java Platform Group at Oracle. There are numerous cases where we want to describe some functionality in code, while clearly expressing that some elements can be ignored. Java 21 re-introduces the underscore character as a preview feature, to be used for ignoring pattern variables, whole patterns or other kinds of variables outside pattern matching.

Let's continue the employee management example and add an Intern record. Imagine that we would like to write code that processes the first case but does not care about the other cases, as our abstract data type is today. We can express this with default.

Employee employee = // ...
switch (employee) {
    case Salaried s -> processSalary(s);
	// every new/additional `Employee`
	// will silently end up here:
    default -> stopProcessing();
}

That would indeed make the switch exhaustive, however there is a hidden caveat. While this switch is now exhaustive it is not future proof. If someone adds a new variant in the future, this snippet will never fail to compile or execute.

The compiler can do a better job of checking exhaustiveness without a default case. If we want this switch to signal us back a missing case upon recompilation, there is indeed a better option. We include the variants of Freelancer and Intern.

Employee employee = // ...
switch (employee) {
    case Salaried s -> processSalary(s);
    case Freelancer f -> stopProcessing();
    case Intern i -> stopProcessing();
}

Notice that both f and i, in this case, are now unused pattern variables in our code. We can replace both with underscore and make our intention that we do not care about variable names clearer. Since those last two cases do not introduce any variables in the scope on the right-hand side of the cases, we can remove the duplication and write this more succinctly, in one line: a case with multiple patterns that none of them introduces pattern variables.

Employee employee = // ...
switch (employee) {
    case Salaried s -> processSalary(s);
    case Freelancer _, Intern _ -> stopProcessing();
}

This version of the switch is decluttered and offers error reporting upon extension of the data type.

Unnamed pattern variables can be used in nested positions as well, for example when we deconstruct the Salaried employees in this example:

Employee employee = // ...
switch (employee) {
    case Salaried(String _, PayGrade grade) -> processPayGrade(grade);
    case Freelancer _, Intern _ -> stopProcessing();
}

But also for whole nested patterns. Here _ in the first case is an unnamed pattern:

Employee employee = // ...
switch (employee) {
    case Salaried(_, PayGrade grade) -> processPayGrade(grade);
    case Freelancer _, Intern _ -> stopProcessing();
}

There are other valid cases of unnamed variables, for example in try-with-resources when the resource name is not needed.

try (var _ = ScopedContext.acquire()) {
    // ... no use of acquired resource ...
}

Outro

Thanks Angelos, he's the owner of JDK Enhancement Proposal 443 which introduced unnamed patterns and variables as a preview feature in JDK 21. I'll tell you more about that in our Road to Java 25 video series in two years.

Because we're done! Not only with pattern matching and data-oriented programming, but with the road to Java 21. From upgrade hurdles to virtual threads, from better tools and security to improved performance and APIs, and now pattern matching, we've covered everything new between Java 17 and 21.

We really enjoyed creating this series and everybody invested a lot of time and energy to make the best videos we could. If you liked them and have the chance, leave a few nice words for Ana, Billy, and Jose in the comments here or under their videos - I'm sure they'll love to read them! Another person who deserves praise is David Delabassee who created the intro, the thumbnails, and is generally the good spirit behind our YouTube channel - thank you, David!

All that said, I hope to see you again in the next weeks and months for our regular programming: JEP Cafes, Stack Walkers, Inside Java Newscasts and Podcasts, conference talks, and more - this is the best place on YouTube to learn deeply about Java. Subscribe and I'll see you around. So long...

Watch the video.

Modern Java in Action

Nicolai Parlog — Sun, 03 Sep 2023 00:00:00 GMT

Let's write a GitHub Crawler and let's throw in everything Java (23) has to offer

So you learned about all these new Java features but want to see how they come together? Then let's write a GitHub Crawler and let's throw in everything Java (22) has to offer:

virtual threads and structured concurrency
pattern matching and data-oriented programming
type inference, records, and sealed types
text blocks ~~and template strings~~
a modern HTTP client and improved collections
modules and OS-specific binaries

The end result will look very different from just a few years ago, let alone 10. This is not your parents' Java!

Upgrading From Java 17 To 21: All You Need To Know

Nicolai Parlog — Sun, 27 Aug 2023 00:00:00 GMT

Java 21 is chock-full of great features but that's for naught of you can't actually upgrade, so I've collected all potential upgrade hurdles and we'll go over every issue that you may encounter on the road from Java 17 to 21

Java 21 is chock-full of great features and if you're coming all the way from 17, there's a plethora of additions to use and get used to. From pattern matching to sequenced collections and countless API additions, from faster GC and overall performance improvements to better security, from virtual threads to better JFR and much, much more - you'll see improvements in all areas. And that's all great and in the coming weeks we'll tell you all about that in the "Road to 21" video series that you're currently watching the first episode of.

But it's all for naught if you can't actually update. And while there isn't one big hurdle, there are plenty of small ones that may cause hiccups when you're moving your project to Java 21. So to make sure that you can hit the ground running, I've collected them all and we'll go over every issue that you may encounter on the road from Java 17 to 21, although I'm sure most of you will only see a tiny fraction.

We'll cover changes in existing APIs that may require you to update your code, ongoing deprecations, and who better to do that than Dr. Deprecator himself, changes in networking and encoding, runtime and tools. If you want to follow up on any of this, there are plenty of links in the description. But we'll also go beyond the nitty-gritty details and see the bigger picture of how to best prepare and execute your Java and 3rd party updates.

Ready? Then let's get on the road! The metaphorical one. I'm not gonna get in a car or anything. I'll be right over there at my desk. Roll the intro!

There are two sets of bug fixes that may change your code's behavior

We've made those changes to make room for Loom's virtual threads

We also have two changes on the class-loading front

APIs

Let's start with some API changes.

Sequenced Collections

Several elements have been added to the collections framework and the biggest of them is of course the two new interfaces SequencedCollection and SequencedSet.

We'll get to that, Jose, but we also need to let people know that the introduction of these new interfaces may lead to conflicts with external implementations of the collection interfaces. So if you or your dependencies contain any of those, be aware that you may encounter method naming conflicts or issues with covariant overrides and type inference.

public class StringList
	extends AbstractList<String>
	implements List<String> {

	/* [...] */

	public Optional<String> getFirst() {
		return size() == 0
				? Optional.empty()
				: Optional.of(get(0));
	}
}

// ✅ up to Java 20: compiles successfully

// ❌ since Java 21:
// error: getFirst() in StringList cannot
//   implement getFirst() in List
//     public Optional<String> getFirst() {
//                                 ^
//   return type Optional<String> is not
//   compatible with String

You may have to refactor some code or update a dependency or both to fix that.

XSL Transformations

If you're converting XSLT stylesheets to Java objects with the JDK XSLT transformer, you may encounter this exception if the template is too large:

com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:
Internal XSLTC error: a method in the translet exceeds the Java Virtual Machine
	limitation on the length of a method of 64 kilobytes. This is usually
	caused by templates in a stylesheet that are very large. Try restructuring
	your stylesheet to use smaller templates.

You either need to split it into smaller templates or use a third-party transformer.

Bug Fixes

There are two sets of bug fixes that may change your code's behavior and that you should look out for.

First, Double.toString() and Float.toString() now correctly determine the smallest number of digits that still uniquely distinguish the float or double from its adjacent float or double. So, for example, calling Double.toString(1e23) will now print "1.0E23" instead of 9.a-lot-of-ninesE22.

// 🤔 up to Java 18:
jshell> Double.toString(1e23)
$1 ==> "9.999999999999999E22"

// ✅ since Java 19:
jshell> Double.toString(1e23)
$1 ==> "1.0E23"

The other change concerns IdentityHashMap. Its methods remove(key, value) and replace(key, value, newValue) erroneously compared value arguments to the values in the map with equals even though it's the identity hash map. So that's been fixed, which might mean that code now removes and replaces fewer elements than it used to.

record User(String name) { }

public static void main(String args[]) {
	var users =
		new IdentityHashMap<String, User>();
	String key = "abc";

	// add a (key, user) combination
	users.put(key, new User("Jane Doe"));
	// try to remove an EQUAL but
	// not IDENTICAL combination
	var removed = users
		.remove(key, new User("Jane Doe"));

	// according to the `IdentityHashMap`
	// contract there should've been no
	// removal

	// ❌ up to Java 19: assertion fails
	// ✅ since Java 20: assertion passes
	assert !removed;
}

Ongoing Deprecations

Dr. Deprecator here with some deprecation news between JDK 17 and JDK 21.

`Thread` And `ThreadGroup`

First, let's start off with the Thread API: The Thread.stop, Thread.suspend, and Thread.resume APIs have now been changed, so that they unconditionally throw UnsupportedOperationException. They don't actually operate on the target thread. We've made those changes to make room for Loom's virtual threads. If your application uses any of those Thread APIs, you're gonna have to change it. We also made some changes to the bulk operations on ThreadGroup.

Security Manager

Another area to keep your eye on is the security manager. It was deprecated for removal in JDK 17. One change you'll need to make in JDK 21 is to make sure to set the java.security.manager property to allow, in order for your application to call the setSecurityManager API.

Another change we're contemplating is, even in the future, after we removed the security manager, are we still going to have the getSecurityManager API return null. Most things that use security features only do the check permissions test if getSecurityManager returns non-null.

if (System.getSecurityManager() != null) {
	// check permissions
}

So if you're still calling getSecurityManager and you test it properly for null, your code will continue to work in the future.

Finalization

Another area to look out for is finalization. That's still deprecated for removal but it still exists in JDK 21. If you want to find out if your application uses finalization, you can disable finalization from the command line. Provide the --finalization=disabled option on the command line and run your application and see if it is affected by having finalization disabled. If your application is relying on finalization, you should take a look at your code and see if you can convert it to use try-with-resources or cleaners instead of finalization.

Other Deprecations And Removals

Some additional APIs have been marked as deprecated. They include Subject.doAs, the m-let mechanism, the SynthLookAndFeel.load API that takes a URL, and also several URL constructors.

A couple of things have been removed since JDK 17. One of them is the java.lang.Compiler API. Closely related to that API is a system property called java.compiler. You used to be able to set that on the command line to effect the JIT compiler, but that's been removed as well.

Dynamic Agents

Another change in JDK 21 is that dynamic loading of agents will now issue a warning. Certain libraries such as Mockito in particular will load agents dynamically and thus they will start issuing a warning. In the future dynamic loading of agents may be disabled by default.

That's it for deprecation news. Back to you, Nicolai.

How To Learn More

Thank you, Dr. Deprecator! I see you've been hard at work, making everybody's life more complicated. But I understand it's necessary: We need to unravel some bad or just outdated decisions, so Java can keep moving forward. And there are plenty of ways to ease deprecations and other migration challenges. Here are a few ways how you can make your life easier:

Build More

First and foremost, please build on more Java versions than just the one you're baselining on. I recommend to build on:

your baseline Java version, for example Java 11
every version after that that gets long-term support, in this example 17 and very soon 21
the latest version, at the moment that's still 20, again soon that's 21
and on the early-access builds of the next version, so now that's 21, but in fact JDK 22 EA builds are already available, so you could do that already as well

You don't need to build every commit on all these versions if that takes too long or too many resources - a nightly build would suffice. And if only parts of your build work, maybe only half the subprojects, then run only those. Or deactivate troublesome tests on specific Java versions. The goal here is to become aware as early as possible whether a technology you use or a change you make causes problems on newer Java versions and for that you need to build as much of your code base as possible.

More News

If you want to accompany the practical approach with some theory, you have quite a few options:

You can subscribe to this channel! We regularly cover these developments, for example all ongoing deprecations in Inside Java Newscast #41.
You can regularly visit inside.java, or, if you're above 40 years old, subscribe to the RSS feed. Inside.java aggregates all important developments in OpenJDK and changes like these pop up there.
When a new Java version is released, you can go over the release notes. I know that sounds old-school and boring but, look, there are sections like Removed Features and Options, Deprecated Features and Options, and Known Issues!
Similarly, Javadoc has a list of deprecated APIs and since JDK 19, you can filter by which version something got deprecated. Cutting edge!

If you want to become more active and feed your experience back into the community, my colleague David Delabassee has something for you. But before we get to that, let's look at some changes in networking and encoding.

Networking

In the spirit of every improvement breaks someone's workflow, we got some in networking that I would descibe as very positive but may require some code changes.

On Windows, network interface names in Java now equal those assigned by the operating system. You probably need to update calls to NetworkInterface::getByName.

var net = NetworkInterface
	.getByName("eth0");
System.out.println(net);
System.out.println("---");
NetworkInterface
	.networkInterfaces()
	.map(NetworkInterface::getName)
	.forEach(System.out::println);

// Example output up to Java 20 / 🪟:
//
// name:eth0 (WAN Miniport (IPv6))
// ----
// lo
// net0
// eth0

// Example output since Java 21 / 🪟:
//
// null
// ----
// ethernet_0
// ethernet_32768
// loopback_0

When you're using the URL class, first, you probably want to reconsider that and switch to URI instead. But anyway, if you are using it, be aware that parsing and validation of the URL string moved from calls like URL::openConnection and URLConnection::connect to the constructor, so you may get exceptions there when you didn't before. You can set the system property jdk.net.url.delayParsing to configure the old behavior if need be.

Similarly, built-in JNDI providers are now more strict with the URLs they accept. If that's an issue, you can use these system properties to configure their behavior:

for "ldap:" URLs: com.sun.jndi.ldapURLParsing
for "dns:" URLs: com.sun.jndi.dnsURLParsing
for "rmi:" URLs: com.sun.jndi.rmiURLParsing

The last network-related change I have for you concerns the HTTP client that was added in Java 11. The idle connection timeout was lowered from an extremely lenient 20 minutes to 30 seconds and can now be configured with the system properties jdk.httpclient.keepalivetimeout and jdk.httpclient.keepalivetimeout.h2 (for HTTP/2).

Encoding

UTF-8 By Default

For the next topic, we can sit back and watch past Nicolai do the heavy lifting.

11110000 10011111 10010101 10001010

What's that? Well, if you interpret it as a bit pattern that encodes a string in UTF-8, it's the peace dove "🕊️". Whereas if you think it's Windows-1252 encoded, it's whatever "ðŸ•Š" could be. As you can see (and probably already know), encoding matters, particularly for a language that's big on "write once, run anywhere".

That's why Java APIs that deal with reading and writing files usually have overloads that let you specify a file's encoding. But you don't have to specify one, in which case Java usually uses the so-called default charset. This default used to be chosen based upon the operating system, the user's locale, and other factors. In JDK 18, this default will always be UTF-8, so Java programs are more predictable and portable when relying on the default.

For most projects, this change will go unnoticed. Those that embrace portability by passing charset arguments as well as those setting the system property file.encoding to UTF-8 will see no impact at all. Those who do neither but target MacOS or Linux are most likely already using UTF-8 because it's usually the default on those operating systems. This mostly leaves programs that target Windows and implicitly rely on its non-Unicode-encoding at risk.

The best way to fix any issues is to either switch to UTF-8-encoded files or always pass a character set to the relevant APIs. When that isn't possible or desirable, take a look at JEP 400 for how to use the new file.encoding value COMPAT, the new system property native.encoding, and the compiler's -encoding flag to tackle problems. If you're not switching to JDK 18 any time soon, the best way to prepare is to set file.encoding to UTF-8 now and shake out any issues over the coming weeks and months.

Besides JEP 400, there's also a great article by Naoto Sato on this topic - linked below of course.

CLDR Version 42

The JDK also regularly updates the Unicode version it's using and that can occasionally cause hiccups. Particularly the update to Unicode CLDR version 42 may not go unnoticed:

in formatted times, dates, and units, it replaced regular spaces with non-breaking and narrow non-breaking spaces

var midFormat = DateTimeFormatter.ofLocalizedTime(FormatStyle.MEDIUM);
// up to Java 19: ` 6:14:18 PM`
// since Java 20: `6:14:18 PM` (narrow space before "PM")
System.out.println( LocalTime.now().format(midFormat) );

some date/time formats no longer say " at " between between date and time or time range

var longFormat = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG);
// up to Java 19: ` August 27, 2023 at 6:14:18 PM CEST`
// since Java 20: `August 27, 2023, 6:14:18 PM CEST` (no "at" after "2023")
System.out.println( ZonedDateTime.now().format(longFormat) );

it fixes the first day of week info for China
expanded support for Japanese numbers
and introduced a few more small changes

These changes mostly impact the presentation layer but if you have code, production or test code, that parses strings, things may start failing. And it can be a little tricky to analyze because your terminal or IDE might make it impossible to distinguish between a space and a non-breaking space. So if you see weird failing tests around date/times where expected and actual look the same, think back to this and drop them into an editor that highlights non-standard characters.

If the required fixes cannot be implemented, you can set the JVM argument java.locale.providers=COMPAT to use legacy locale data but note that this limits some locale-related functionality and treat it as a temporary workaround, not a proper solution. Particularly because the COMPAT option will be removed in the future.

Quality Outreach

Zoom ringtone

Hey David!

Hi Nicolai.

We're talking about hurdles when upgrading to new Java versions and you said you have something for us?

Yes, I'd like to quickly introduce the OpenJDK Quality Outreach program. So it's a program where we encourage open source projects to do their tests on early-access builds of OpenJDK. The idea is pretty simple: If there is an issue in those early-access builds, we'd like to know it sooner rather than later as it gives us a chance to address that issue before that particular version is generally available. And, in the end, that's a win-win situation: It's a win for the open source project as that project will run, starting day one, on the newer Java version, but on the other hand it's also a win for the OpenJDK community at large as those reports help to improve the overall quality of OpenJDK builds.

So who can participate in this?

So, any open source project can participate in the program. And it's pretty easy: A contributor or a maintainer of the project just needs to ping us and we'll enroll the project in the program.

Say I exclusively work on closed-source software, what can I get out of Quality Outreach?

So, if you work on a closed-source project, in fact you are already getting benefits out of the Quality Outreach program. As I mentioned earlier, this program improves the overall quality of OpenJDK builds, so everybody benefits from this program. Now, as part of the program we also issue regular Quality Outreach Heads-ups. In those heads-ups we cherry-pick improvements, changes, or fixes, small or big, to draw attention to those - it can be a behavior change due to a fix that addresses a compatibility issue and so on and so on. So we communicate those changes and often we provide some best practices, we document how to keep the old behavior should this be required, and so on and so on. It's, again, the type of information that you ideally want to know sooner rather than later. And those heads-ups are useful regardless of your project. Open source or closed source, it doesn't matter because in the end we are talking about the Java platform, right?

And where can I find these outreaches?

So, those heads-ups are sent to all projects enrolled in the Quality Outreach program, but in addition they are also published on inside.java and we have a dedicated page inside.java/headsup.

See, I told you that inside.java is very helpful! Thank you David for letting us know about Quality Outreach. Bye!

Bye!

Time for us to tackle the last two topics: The JDK runtime and tools and then 3rd party projects.

Runtime

On the runtime front you should be aware of a few VM options that are going away.

Obsolete Options

Biased locking was disabled by default and deprecated in JDK 15 and now related VM options like UseBiasedLocking are obsolete:

UseBiasedLocking
BiasedLockingStartupDelay
BiasedLockingBulkRebiasThreshold
BiasedLockingBulkRevokeThreshold
BiasedLockingDecayTime
UseOptoBiasInlining

G1's remembered sets and concurrent refinement threads were refactored or replaced entirely, which impacts options G1RSetRegionEntries and G1RSetSparseRegionEntries as well as G1UseAdaptiveConcRefinement and... all these:

G1ConcRefinementGreenZone
G1ConcRefinementYellowZone
G1ConcRefinementRedZone
G1ConcRefinementThresholdStep
G1ConcRefinementServiceIntervalMillis

For background info on this and a summary of all the cool garbage collection improvements, check out the RoadTo21 episode on GC & performance next week.

G1 region size can now be set up to 512 MB, previously it was 32. This can be helpful for reducing memory fragmentation on applications that work with a lot of large objects. G1 now uses a single mark bitmap instead of two which can save about 1.5% of heap space.

But back to these options. For now, using them will result in an obsolete option warning but once they're fully removed, you'll get an unknown option error instead. Either way, removing options that don't do anything is highly recommended to ease understanding and maintainability.

Class Loading

We also have two changes on the class-loading front:

If you're running bytecode that was compiled on Java 1.4 or earlier, you can have classes with a name that end in a forward slash. That isn't legal, though, and JDK 21 will enforce the JVM specification and throw a ClassFormatError upon encountering them.

The other change is a bit weird and I don't understand it well enough to give you a short explanation, so instead I'll describe under what circumstances you may want to check out the link in the description (remember, there are follow-up links for everything I mention here):

if you're having a custom class loader
that does not register as parallel cabaple
or if it's pre-dating JDK 7

Got that? Good. If that sounds familiar, check the link.

Metal 🤘

The last item on the runtime list is for desktop application developers: On macOS Java now uses the Metal rendering pipeline instead of the Apple OpenGL API. If that's a problem for you, you can revert to OpenGL by setting the system property sun.java2d.opengl to true. But given that all Apple devices running at least macOS 10.14, which was released five years ago, support Metal, maybe see that property as a temporary workaround.

Tools

Now let's come to a few small changes to various JDK tools that may require you to update your build tool configurations or scripts:

If you compile with lint:serial, note that you will now get a warning if a serializable type has a non-serializable and non-transient instance field.

The jar tool no longer generates an index. Its option --generate-index is hence ignored and leads to a warning, and the runtime ignores an index if it's present.

jlink's option --compress now accepts values zip-0 to zip-9 instead of the more abstract 0, 1, 2. This is actually caused by an addition to jmod:

The main purpose of jmod is to create a module file having the jmod extension that encapsulates a set of compiled Java classes, resources, and other related files. You can distribute these module files to be consumed by other modules or applications. In order to specify a compression level while creating the jmod archive, you can use the --compress command line option.

You can learn more about that and all the good stuff that changed in Java tools in Ana's RoadTo21 video on the topic once it's out.

Finally, if you're using jpackage --app-image, you can expect more diligent checking of some requirements, like the presence of the .jpackage.xml file, and thus potentially new errors if your build config was faulty.

My guess is that most of these changes to JDK runtime and tools don't concern you, though, or are very easy to fix with removing or reconfiguring an option here or there. The next topic may require a bit more work, though.

3rd party tools

Because it's not only your code that can be impacted by changes like this, it also happens to the tools and dependencies you rely on. One regular change in particular causes issues for some of them and that's the increase in bytecode level. When you compile with target 21, for example, the compiler embeds the bytecode level that corresponds to that Java version, 65 in this case, in the generated bytecode. And bytecode manipulation libraries like ASM and bytecode analysis tools wisely avoid working on bytecode from a level they weren't written for.

There's some work being done on improving this situation but for now a JDK update often entails updates of all tools and dependencies that manipulate bytecode, which may be a few more than you're initially aware of. Fold in all the other changes we talked about and the unfortunate reality is that you may have to update most of your tools and dependencies. Then again, it's probably a good practice to do that anyway, so I really hope the step from JDK 17 to 21 is not the only occasion on which you update other stuff.

Updating dependencies neatly leads us to the last topic I want to discuss with you today and that's how to go about a JDK update. Where to start and where to go from there?

How to

In my opinion, the best approach is the gradual one. Follow my advice from earlier and build on each JDK version as it's being developed and then go over the release notes once it's released and you'll catch most of these issues very, very early and adapt to them step by step. At least to those that can be adapted to in a way that keeps working on your baseline Java version. You can already refactor methods that conflict with sequenced collections, split your large XSLT stylesheets, reduce the use of deprecated mechanisms, set the default encoding to UTF-8, and generally update dependencies as they become compatible with newer Java versions. But of course you can't change the values you pass to jlink --compress to ones that don't yet work on JDK 17, for example, or use the actual network device names on Windows - those changes should go on a list, probably with some pointers to which of your classes they'll impact, that you pull out when it's time to do the update.

And when that time rolls around, step zero is always: update your dependencies and tools. Again, you should be doing that regularly anyway for a host of reasons, but specifically in this situation. Then, don't jump from 17 to 21. Or rather, try that but as soon as you see issues, go back to 18, then 19, and so forth. I'll leave a link to the JDK archive in the description, so you can easily find those versions. Just don't run them in production! This allows you to pinpoint which Java version causes an issue you observe and helps immensely with research, starting with the release notes and followed by a search with that version as one of the terms.

And... that's it. Unfortunately, there is no one weird trick that makes all updates super simple. The only simple move, would be not to play. 😉 But then, you don't get to all the good stuff that comes with new Java versions and now that we got the hard work out of the way, we can play. Here are a few snippets from the videos we made for you and that will come out between now and the JDK 21 release. You don't want to miss this...

Highlights

You will learn how the JDK 21 will make your work easier. We will cover the String class, collections framework...

Enter jwebserver, a minimal HTTP static file server.

Generational ZGC is arriving with JDK 21.

... date-and-time API, the HTTP client API ...

Patterns, switch, and sealed types

This is exactly the role of a virtual thread and instead of blocking the platform thread, it unmountes itself from this platform thread.

The JDK Flight Recorder captures events related to cryptographic operations and in JDK 20 two more events were added.

Just like lambda expressions turned the strategy pattern into a language feature, does pattern matching turn the separation of types and operations into a simple application of a few language features.

... concurrent programming, the Math API, and BigInteger.

Watch the video.

Java 21 is no LTS Version - Inside Java Newscast #52

Nicolai Parlog — Thu, 06 Jul 2023 00:00:00 GMT

Let's separate Java from JDK, OpenJDK from its vendors, and maintenance from support, so we better understand how the ecosystem functions and what long-term support really means.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and I'm bringing bad news: Java 21 is no long-term-support version.

Ok, I'm not gonna beat around the bush here. You'll find plenty of JDK 21 builds that get free, timely updates for the coming years - Oracle JDK 21, for example. And you will find plenty of companies that give you extensive support for their builds - Oracle, for example. But that doesn't make Java 21 a long-term support version, just like 17 and 11 weren't LTS versions.

And while that detail doesn't matter if all you care about is writing code, you'd not be watching this channel if that were all you're interested in. So let's geek out a bit and separate Java from JDK, OpenJDK from its vendors, maintenance from support, so we better understand how the ecosystem functions. And lets get me some new milk while we're at it. Ready? Then let's dive right in!

Java vs JDK

First things first: Java 21 isn't anything, except possibly a shortcut for Java Platform, Standard Edition 21.

But you can't download that - it's not a binary, it's not code. It's a set of specifications that define the behavior of a language, its API, a virtual machine, and a few more things. The thing that gets new commits is the Java Development Kit, the JDK, in this situation specifically JDK 21.

That's a code base that contains the reference implementation of the Java SE 21 specification. It's developed by OpenJDK and can hence be found on github.com/openjdk/jdk21. That code base gets updates until JDK 21 is released. At that point, OpenJDK no longer has to concern itself with it.

By the way, I'm saying OpenJDK a lot. In the briefest of terms, that's a place where a community of individuals work together to create the open source reference implementation of the Java Platform, Standard Edition as well as some related projects. For much more details on that, I'll refer you to Inside Java Newscast #28.

So what happens when JDK 21 is released? The fork jdk21 is archived and focus shifts to jdk21u, which contains all the fixes that the community wants to provide for JDK 21 after its release. And this is where we need to start differentiating between maintenance and support.

Maintenance

So what happens to jdk21u? That's up to the OpenJDK community. Since the six-month release cadence was implemented, Oracle's Rob McKenna, Project Lead of the JDK Updates Project, was lead maintainer for each jdk$VERSIONu project for its first six months. After that, he steps down to work on jdk$VERSION+1u and offers the lead maintainer role for jdk$VERSIONu to any trustworthy community member who wants to step up.

For some versions, like 11, 17, and probably 21 that happens and the fork sees continued fixes. But there are no guarantees that this happens, no contractually defined time span for how long it's kept up, and nobody who's obliged to fix your problem. It's not an official term but I would call these versions maintained. For other versions, nobody steps up, the fork is closed, and OpenJDK sees no more updates to that version.

Viewed from the perspective of OpenJDK, which version gets maintained and which doesn't appears random, though. There's no rule that says jdk21u needs a maintenance lead and a community behind them and that jdk20u can't have that. It just happens - or does it?

Support

Well, of course it doesn't just happen. Maintaining a JDK version is a lot of work and thus requires a considerable amount of time from quite a few people. Most or even all of them don't do that in their free time - their companies pay them to. But why would they do that? Why would companies and large corporations invest valuable resources into maintaining an old JDK update fork?

For many of them, the answer is that it makes business sense because, one way or another, they profit from a well-maintained JDK version. Be it because they run it in their own cloud, offer software built on Java, sell Java support to their customers, or for a number of other reasons.

Let's focus on support, though. Exactly which services and guarantees that entails, how much it costs, and how long it lasts differs from vendor to vendor, but the high-level view is that they build a JDK, possibly from the OpenJDK update fork we just talked about plus maybe local replacements or patches, and you pay them for support for that build - potentially for a long time.

And here we are - this is long-term support: A company's offer to provide services and guarantees for their certified Java implementation, that may or may not be built from an OpenJDK update fork.

Maintenance in OpenJDK vs Support by Vendors

I hope you can see the distinction now. OpenJDK will maintain JDK 21, the reference implementation of the Java Platform SE 21 specification, within its community and without any guarantees, services, or even builds for at least 6 months, in all likelihood for a few years. Vendors, on the other hand, will build their own JDKs, often from the OpenJDK code base. They may make them freely available and on top of them they may offer commercial support, which incentivizes them to contribute to the OpenJDK effort of maintaining these versions.

So instead of "Java 21 is an LTS version", it's "JDK 21 is a version, for which many vendors offer support". This distinction, just like the one between maintenance and support, might appear pedantic, but it's important when you try to understand the roles of different community members.

Say you buy a carton of milk and upon opening it notice that it spoiled, where do you take it? To the cows? To the farmer who milked them? No, you're going to the party that you paid - the supermarket - and demand from them to fix the problem. There's probably a lesson in here about getting your milk from a roadside vendor who gives it away for free, but let's not go there. Instead I want to get back to something I said earlier.

(But, and I know you're wondering: Yes, the whole setup with the milk and with the hike was just to show you these two cows. There're usually way more here on that field. I hope it was worth it.)

A Prisoner's Dilemma

I said earlier that vendors are incentivized to contribute to the OpenJDK effort of maintaining the jdk21u project. Why is that? Why do many of them share so much of their work with the wider community? And why do they mostly support the same versions? Come September, you won't be able to throw a rock without hitting a company that has offers for JDK 21, but you better not hope anybody will support JDK 20.

Again, there are several reasons, but an important one is that a JDK patch that a company has developed and not shared with the community is generally not an asset, but a liability. It creates a divergence between their code base and OpenJDK's and the more of that and the larger they are, the more work they will cause. And while that may be beneficial if a company commercialized a specific offer around such changes, in general such a patch has little benefit, since everybody else probably fixed the same problem. So in most cases, companies are incentivized to upstream their own patch and, if it didn't make it, remove their own in favor of the one that did.

I like to describe this as an inverse prisoner's dilemma, where everybody profits if they cooperate. And so while, in theory, every company could offer support for wildly different versions and time spans, they rarely do and instead settle on largely the same versions and time lines. And I gotta say, given that many companies in the Java community are competitors, sometimes in more than one area, the level of coordination and cooperation this structure creates is astonishing. Pretty amazing what's going on in the Java community...

Outro

And that's it for today on the Inside Java Newscast. I hope you liked it, if so, do all the YouTube things. The next two episodes will be with Billy and Ana and then the Newscasts are gonna take a little break because we'll have something special for you leading up to the JDK 21 release in September. I'll probably see you again in a Newscast in October. So long...

Watch the video.

Java 21 - The Other Side - Inside Java Newscast #51

Nicolai Parlog — Thu, 22 Jun 2023 00:00:00 GMT

OMG, how is there even more in JDK 21?! Scoped values preview, key encapsulation mechanism API, a new JFR command, and various API improvements. Generational Shenandoah is out, though, and it doesn't look good for the 32-bit Windows port either.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java Developer Advocate at Oracle, and I gotta say I'm a bit frustrated. Making timely content for the start of rampdown phase 1 is haunting. Over the two weeks it took me to script, record, and edit the last video, a few more features got added - from JFR to a new API to a handful of smaller additions to existing ones - one feature got removed, and I might've missed one or two details. Oh, and new deprecations! So we're gonna go over all that today, think of this episode as "What's happening" part 2 - the other side. Ready? Then let's dive right in!

Scoped Values

The ThreadLocal API is used to store thread-specific information, usually in static final fields, which can then be queried from anywhere that variable is visible. That's useful, for example, when a container, like a web server, needs to make information accessible to other parts of its code that it doesn't call directly but it doesn't want to pass that information on explicitly, either for convenience or integrity reasons.

class Server {

	// `Principal` needs to be visible to other code...
	final static ThreadLocal<Principal> PRINCIPAL = new ThreadLocal<>();

	void serve(Request request, Response response) {
		var level = request.isAuthorized() ? ADMIN : GUEST;
		var principal = new Principal(level);
		PRINCIPAL.set(principal);
		// ... but not the application
		Application.handle(request, response);
	}

}

But ThreadLocal has a few shortcomings:

Anyone with access to the ThreadLocal field can not only read its value but also set a new one.
Values stored in ThreadLocal can be inherited from one thread to another.

In order to prevent the other threads from reading an updated value (which the API should explicitly prevent - it's thread local after all), the inheriting thread must create copies. These drive up memory use, especially when there are many threads - you know, the whole "millions of virtual threads" thing. 3. Once set, values must be explicitly removed (using the ThreadLocal::remove method) or they will leak beyond their intended use and continue to occupy memory.

To solve these problems, Java 20 incubated and Java 21 previews the scoped values API, which works by binding a value to the ScopedValue instance and passing the code that is allowed to read that value as a lambda - that's the scope.

class Server {

	final static ScopedValue<Principal> PRINCIPAL = new ScopedValue<>();

	void serve(Request request, Response response) {
		var level = request.isAdmin() ? ADMIN : GUEST;
		var principal = new Principal(level);
		ScopedValue
			// binds `principal` to `PRINCIPAL`, but...
			.where(PRINCIPAL, principal)
			// ... only in the scope that is defined by this lambda
			.run(() -> Application.handle(request, response));
	}

}

It addresses the ThreadLocal issues:

Within the scope, the bound value is immutable.
Accordingly, no copies need to be created when inheriting, which significantly improves scalability.
As the name implies, a scoped value is only visible within the defined scope - after that the value is automatically removed and so cannot accidentally leak.

To see scoped values in practice, watch JEP Café #16. In it, Jose talks about the version of the API as it was in JDK 20 but all that changes in 21, besides moving to java.lang, is that the scope, the lambda, can now be a Callable, Runnable, and Supplier.

No Generational Shenandoah

So, two weeks ago was June 8th, the beginning of rampdown phase 1, when all JEPs that target a JDK release are locked in. Two hours before the Newscast goes live, news reaches me that 18 hours earlier Roman Kennke, owner of the generational Shenandoah JEP, proposed to drop it from JDK 21. I hope you forgive me that I decided against recording a correction and then editing, rendering, uploading, and configuring the video in favor of catching my plane home. Although, now that I say it out loud, I should've made the correction and charge Oracle for another week of holidays.

Well, that ship has sailed. Unlike the generational Shenandoah one. On the issue, Roman wrote:

The Shenandoah team has decided to skip JDK21 and take the time to deliver the best Generational Shenandoah that we can.

6-month release cadence for the win! JDK 22 is basically around the corner and I hope we see generational Shenandoah, then.

Key Encapsulation Mechanism API

Do you know the Diffie–Hellman key exchange algorithm? If you don't, you should definitely look into it - on the face of it, it sounds impossible. It lets two parties compute an encryption key, a number, while an observer that sees every exchanged message cannot feasibly redo the computation, so that key is a secret that only the two parties know. As you can imagine that's very helpful when you need to exchange encrypted information between parties that have no prior knowledge of each other. Diffie–Hellman is hence widely used, for example to provide forward secrecy in TLS.

Diffie–Hellman can be understood as an instance of a key encapsulation mechanism. Such mechanisms are a building block of Hybrid Public Key Encryption and will be an important tool for defending against quantum attacks. Starting with JDK 21, Java has an API to represent key encapsulation mechanisms in a natural way.

Now you're wondering what that looks like. Shouldn't I go into explaining that? But that stuff is just too complicated for me... But I don't have the time in this episode... ... and so I asked Ana to record a Newscast on this topic. Probably in August - better subscribe so you don't miss it.

Platform Integrity and Dynamic Agents

Integrity of the Java platform is a very interesting topic. It's not flashy like new language features or APIs or tools, but it is very deep and essential for our use of Java. We enjoy many invariants, from the initial value of variables to type safety, from array range checks to no "use after free". And integrity guarantees that these invariants are actually invariant - that no code can undermine them! This helps with correctness, maintainability, security, and performance. But Java offers a few ways for code to undermine these guarantees, intentionally or inadvertently.

Ron's Take on Integrity

But anyway, we have this deep reflection in Java and it means that we cannot trust anything. You try to establish an invariant but you're back to C: The only way you can know if it holds or not is if you analyze the entire code base and all of your dependencies. And it is violated, even accidentally. Even though everyone is well-meaning, no one here is malicious, your invariants do get broken.

Now, the big shift toward allowing you to establish integrity invariants in Java was the addition of modules in JDK 9. The idea was that a module is an encapsulated unit that is strongly encapsulated, so it prevents setAccessible unless you explicitly allow it. So with modules you say, "ok, now can I trust, now I can establish integrity invariants in Java, now my encapsulation works". Only there are ways to circumvent it.

You can have an ordinary library, again, a dependency of a dependency of a dependency and it does happen. We did a corpus search... we need to stop it because it happens. It loads an agent dynamically, which means that the application owner does not know it does that, and that agent, what you can do is: The setAuthorized method that does the authorization check? It changes it to always return true.

Any library! Any library on your class path can change the meaning of any other line of code in your program without you knowing it due to dynamically loaded agents. Not statically loaded agents - statically loaded agents are fine because the application owner says: "I'm allowing this agent to work. I know - I take the risk."

Two others are Unsafe, which will gradually go away, and JNI. So if you use JNI, JNI is not subject to any of the access checks, so what we will need to do is to say... On the command line you will say "I'm allowing these modules to use JNI."

JDK 21's Change for Dynamic Agent Attachment

That was from a conversation with Ron Pressler about this topic that we had during the 28 hours live stream. It was really interesting and we went quite deep - we'll probably upload that in the coming weeks.

So what you heard there is that modules can guarantee platform integrity but are undermined by three mechanisms: Unsafe, agents, and native code (JNI and FFM). Over the coming years, Unsafe will go away and the other two will have to be allowed explicitly by the application owner via command line flags. For agents, that is already the case for those launched statically, in tandem with the application, but dynamic attachment at run time can still happen without you knowing. In a first step to fix that, and that brings us back to this episode's topic, JDK 21 will issue a warning when an agent is attached at run time. In the future, this will very likely not be possible without setting a command line flag.

New JFR Command

The JDK Flight Recorder is an amazing piece of tech and it's getting better with every JDK release. 21 added the view command that displays aggregated event data on the terminal. This way, you can view information about an application without the need to dump a recording file, or open up JDK Mission Control. This topic, I pawned off to Billy, expect a Newscast on that in July.

API improvements

JDK 21 comes with a number of small additions to existing APIs. Let's quickly go over them, so you're aware where the JDK can do your work for you:

Character got a few static checks that let you identify emojis, first and foremost isEmoji.

var codePoint = Character.codePointAt("😃", 0);
var isEmoji = Character.isEmoji(codePoint);
// prints "😃 is an emoji: true"
System.out.println("😃 is an emoji: " + isEmoji);

Math got static clamp methods that take a value, a min, and a max and return a value that is forced into the [min, max] interval. It has four overloads for the four numerical primitives.

double number = 83.32;
double clamped = Math.clamp(number, 0.0, 42.0);
// prints "42.0"
System.out.println(clamped);

StringBuilder and StringBuffer got repeat methods, which allow you to add a character sequence or a code point multiple times to the string that is being built.

var builder = new StringBuilder();
builder.append("Hello");
builder.append(", ");
builder.repeat("World", 3);
builder.append("!");
// prints "Hello, WorldWorldWorld!"
System.out.println(builder);

String's indexOf methods got overloads that take a maxIndex ...

var hello = "Hello, World";
var earlyCommaIndex = hello.indexOf(",", 0, 3);
// prints "-1"
System.out.println(earlyCommaIndex);

... and its new method splitWithDelimiters behaves like split but includes the delimiters in the returned array. The same splitWithDelimiters was added to Pattern, by the way.

var hello = "Hello; World";
var semiColonSplit = hello.splitWithDelimiters(";", 0);
//prints [Hello, ;,  World]
System.out.println(Arrays.toString(semiColonSplit));

Need to shuffle a List in place with a RandomGenerator? Then that's your reason to update to JDK 21! Once you did, you can pass the list and a RandomGenerator to Collections::shuffle and it shuffles the list.

var words = new ArrayList<>(List.of("Hello", "new", "Collections", "shuffle", "method"));
var randomizer = RandomGenerator.getDefault();
// using this API makes way more sense, when you're not using the default generator
Collections.shuffle(words, randomizer);
// prints the words above but with 99.17% chance in a different order
System.out.println(words);

An HttpClient can now be instructed to close, to shutdown, or to awaitTermination but those are best-effort implementations that can have adverse interactions with open request or response body streams.

var httpClient = HttpClient.newHttpClient();
// use the client
httpClient.close();

// or call `shutdown` and `awaitTermination`
// yourself for more control:
var httpClient = HttpClient.newHttpClient();
// use the client
httpClient.shutdown();
httpClient.awaitTermination(Duration.ofMinutes(1));

// it also implements `AutoCloseable`
try (var httpClient = HttpClient.newHttpClient()) {
	// use the client
}

Locale.availableLocales() returns a stream of all available locales.

var locales = Locale
	.availableLocales()
	.map(Locale::toString)
	.filter(locale -> !locale.isBlank())
	.sorted()
	.collect(Collectors.joining(", "));
// prints af, af_NA, af_ZA, af_ZA_#Latn, agq, ...
System.out.println(locales);

And because you've all asked for case-folded IETF BCP 47 language tags, don't act like you didn't, Locale got the method caseFoldLanguageTag.

var lang = Locale.caseFoldLanguageTag("fi-fi");
// prints "fi-FI" (note the RFC5646-correct case)
System.out.println(lang);

As usual, there are links to all of this in the description.

Note:

Those links lead to the Javadoc preview builds, but once JDK 21 is released, they will break. In that case, you can find everything in the final destination, which should be here. You can also get in touch and I will fix the links.

End Note.

32-bit Windows port

Windows 10 is the last 32-bit Windows and it reaches end-of-life in October 2025 and the Java port for 32-bit Windows isn't heavily maintained anymore. For example, its implementation of virtual threads isn't virtual at all - they fall back to platform threads. So I guess it was to be expected, that the port gets deprecated for removal, which JDK 21 does.

Outro

And that's it for today on the Inside Java Newscast. Thank you for watching, I hope you liked it, if so, please let YouTube know and share this video with your friends and colleagues. I'll see you again in two weeks, but with some bad news, I'm afraid... So long...

Watch the video.

All That is in Java 21?! 😱 - Inside Java Newscast #50

Nicolai Parlog — Thu, 08 Jun 2023 00:00:00 GMT

JDK 21 is almost too good to be true: It finalizes virtual threads, sequenced collections, generational ZGC, and the pattern matching basics; and evolves and introduces over half a dozen other features.

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog and I'm out of my mind about JDK 21. Virtual threads, sequenced collections, generational low-pause garbage collection, and the complete pattern matching basics - and that's just the finalized features! Structured concurrency, vector API, foreign function and memory API - they all progress towards finalization. Or is it new previews that you're thirsting for? There are unnamed classes and instance main, string templates, unnamed patterns and variables, and another big GC improvement!

WHAT'S HAPPENING?! Indeed!

Today, the JDK main development line gets forked and JDK 21 enters ramp-down phase 1, which means there will be no new features. So this is a great time to take a whirlwind tour of all that's coming. For deeper dives, I'll point out the other videos we made on these topics. Ready?

No, not yet!

Nicolai from editing here and as if Java 21 isn't overflowing with features already, a few more got added in recent days. I don't cover them in this episode but I will in upcoming ones. I want to at least mention them here for completeness' sake, though.

In the final category, we have the key encapsulation API and progressing from incubation to preview are scoped values - JEP Café #16 covered them. Then we need a section for deprecations. Preparations are undertaken to, in the future, turn the default for dynamic loading of agents from allowed to disallowed and the Windows 32bit x86 port is deprecated for removal. Links to the respective JEPs and everything else mentioned in this episode are, as always, in the description.

Now we're ready!

Then let's dive right in!

Production-Ready

Virtual Threads

Let's start with the big one: After two rounds of preview with barely any changes, virtual threads are final in JDK 21. Now the web frameworks are off to the races as they need to let you easily configure using virtual threads instead of platform threads when handling requests.

Doing that has the potential to let your app handle way more concurrent connections than before. But keep in mind that virtual threads are no performance pixie dust, so keep expectations realistic. Then again, if you don't see the results you're hoping for, there may be some easy code changes that you can do that get you there. Check Inside Java Newscast #23 for more on that and some virtual threads dos and don'ts.

Embedded video.

Sequenced Collections

Many collections in Java have a stable iteration order (all lists and some sets, for example) but don't necessarily allow indexed access to them (which all lists do, but sets usually don't). JDK 21 steps up its collections game and introduces a set of new interfaces that capture this concept and offer related functionality.

At its core is SequencedCollection, which extends Collection and is ultimately implemented by all lists, some sets, and a few other data structures. It offers methods add.../get.../remove... ...First and ...Last, which do what you'd expect.

// getting first and last elements from a list
// (sequenced by order of addition)
var letters = List.of("c", "b", "a");
"c".equals(letters.getFirst());
"a".equals(letters.getLast());

// same but from a sorted set
// (sequenced by natural ordering)
var letterSet = new TreeSet<>(letters);
"a".equals(letters.getFirst());
"c".equals(letters.getLast());

It also has a method reversed that returns a SequencedCollection that is a view on the underlying collection but in reverse order, which makes it super easy to iterate or stream over.

var letters = new ArrayList<>(List.of("a", "b", "c"));
var reversedLetters = letters.reversed();

letters.addLast("d");
reversedLetters.forEach(System.out::print);
// ~> dcba

reversedLetters.addFirst("e");
letters.forEach(System.out::print);
// ~> abcde

If you want to learn more about that, the companion interfaces SequencedSet and SequencedMap, and a few odds and ends, check out Inside Java Newscast #45.

Embedded video.

Generational Low-Pause Garbage Collection

Garbage collection is also taking big steps forward. ZGC has a strong focus on ultra-low pause times, which can lead to a higher memory footprint or higher CPU usage than other GCs. Starting with JDK 21, both of these metrics will be improved on many workloads when ZGC becomes generational, meaning it will maintain separate generations for young objects, which tend to die young, and old objects, which tend to be around for some time.

Preliminary benchmarks show very promising results! In a probably not representative case, Cassandra 4 showed

four times the throughput on GenZGC compared to ZGC with a fixed heap or
a quarter of the heap size on GenZGC compared to ZGC with stable throughput

If you want to give generational ZGC a try on your work load, download a JDK 21 early access build and launch it with -XX:+UseZGC -XX:+ZGenerational. For more details, check JEP 439 or Inside Java Podcast #24 with Erik Österlund.

Embedded video.

Pattern Matching

To effectively use pattern matching, you need three things:

a capable switch that allows the application of patterns
the ability to enforce limited inheritance so the switch can check exhaustiveness
and an easy way to aggregate and deconstruct data

var shape = loadShape();
var area = switch(shape) {
	case Circle(var r) -> r * r * Math.PI;
	case Square(var l) -> l * l;
	// no default needed
}

sealed interface Shape permits Circle, Square { }
record Circle(double radius) { }
record Square(double length) { }

There are other features that come in really handy (and they are being worked on and one even previews in 21 - more on that later), but these are the basics and JDK 21 finalizes the last two pieces: pattern matching for switch and record patterns. Now that we've got everything together, you can use this powerful idiom in your projects - be it in the small or in the large if you use a functional or data-oriented approach. To see how these features play together to achieve that, check out Inside Java Newscast #29.

Embedded video.

Continued Evolution

Done with that, now it's time to transition. For me from one holiday location to the next (btw I'm taking guesses where I am in the comments) and for this video from finalized features to previews, incubations, and experiments. And just a reminder, to use a preview feature, you need to add the command-line flag --enable-preview to javac and java and you also need to specify the Java version for javac, preferably with --release 21.

Structured Concurrency

Once you get abundant virtual threads and start creating one for every little concurrent task you have, an interesting opportunity arises: You can treat threads that you created for a set of tasks as executing a single unit of work and you can see them as children of the thread that created them. An API that capitalizes on that would streamline error handling and cancellation, improve reliability, and enhance observability. And it would make it easy and helpful to start and end that single unit of work in the same scope, defining a unique entry and exit point for handling concurrent code. It would do for concurrency what structured programming did for control flow: add much-needed structure.

Lucky us, this API exists! It's called the structured concurrency API. If you haven't seen this coming a mile away, for one you're not reading the title cards, but you must also have skipped quite a few of our videos. May I suggest subscribing to the channel and liking this video, so this doesn't happen again in the future?

// create task scope with desired
// error handling strategy
// (custom strategies are possible)
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {

	// fork subtasks
	Subtask<String> user = scope.fork(() -> findUser());
	Subtask<Integer> order = scope.fork(() -> fetchOrder());

	scope
		// wait for both subtasks
		.join()
		// propagate potential errors
		.throwIfFailed();

	// both subtasks have succeeded
	// ~> compose their results
	// (these calls are non-blocking)
	return new Response(user.get(), order.get());
} // task scope gets shut down

The structured concurrency API was incubating in JDK 20 and is upgraded to a preview in JDK 21. Beyond moving to a proper package, namely java.util.concurrent, the only change has been that StructuredTaskScope's method fork now returns the new type Subtask. In 20 it returned a Future but that offered degrees of freedom (like calling the blocking get method) that are counterproductive in structured concurrency and was overall too evocative of asynchronous programming, which is exactly what structured concurrency isn't.

Jose had a great JEP Cafe on all this, check out episode #13.

Embedded video.

Vector API

the vector API is in its sixth incubation, still waiting for Valhalla, nothing new to see here, please move on. Unless you want to see vectors in action, then check JEP Cafe #18.

Embedded video.

Foreign Function & Memory API

By efficiently invoking code outside the JVM (foreign functions) and by safely accessing memory not managed by the JVM (foreign memory), the foreign function and memory API enables Java programs to call native libraries and process native data without the brittleness and danger of the Java Native Interface (JNI). One of the main drivers of the FFM API is to provide safe and timely deallocation, in a programming language whose main staple is automatic deallocation (thanks GC). Finding the right primitive to express this capability in a way that is harmonious with the rest of the Java programming model triggered a round of API changes in JDK 20 and again in JDK 21, which is why the API will take another round of previewing.

// 1. find foreign function on the C library path
Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle radixsort = linker.downcallHandle(stdlib.find("radixsort"), ...);

// 2. allocate on-heap memory to store four strings
String[] words = { "mouse", "cat", "dog", "car" };

// 3. use try-with-resources to manage the lifetime of off-heap memory
try (Arena offHeap = Arena.ofConfined()) {
	// 4. allocate a region of off-heap memory to store four pointers
	MemorySegment pointers = offHeap
		.allocateArray(ValueLayout.ADDRESS, words.length);
	// 5. copy the strings from on-heap to off-heap
	for (int i = 0; i < words.length; i++) {
		MemorySegment cString = offHeap.allocateUtf8String(words[i]);
		pointers.setAtIndex(ValueLayout.ADDRESS, i, cString);
	}

	// 6. sort the off-heap data by calling the foreign function
	radixsort.invoke(pointers, words.length, MemorySegment.NULL, '\0');

	// 7. copy the (reordered) strings from off-heap to on-heap
	for (int i = 0; i < words.length; i++) {
		MemorySegment cString = pointers.getAtIndex(ValueLayout.ADDRESS, i);
		words[i] = cString.getUtf8String(0);
	}

// 8. all off-heap memory is deallocated at the end of the try-with-resources block
}

On that note, the quality of feedback during the preview phase from projects adopting the API has been excellent and very important for its evolution. If you want to help move Java forward, the easiest way to do that is to experiment with preview features and report back to the respective mailing lists.

Another addition in 21 has been the so-called fallback linker, which offers a way for platforms to be Java Standard Edition compliant without too much work by using libffi instead of fully implementing the linker API.

Brand New Previews

So how are we doing on time? Ugh, terrible, as expected! But there are three brand-new preview features that we. Just. Can't. Skip. And I love how diverse they are! They span from improving a Java workhorse to refining a programming paradigm to changing how beginners learn the language.

Unnamed Classes And Instance Main

We've just talked about this in the last episode and that video has been doing really great (thank you for that, by the way, I really appreciate it) so in the interest of time, I'm going to assume most of you watched it and keep this part short.

JDK 21 allows for much simpler entry points into a Java program. The main method no longer needs to be public nor static nor does it need the args array. And the whole surrounding class becomes optional, too, making void main the smallest possible Java program.

// content of file `Hello.java`
void main() {
	System.out.println("Hello, World!");
}

Let me briefly clarify two points that I didn't explain very well two weeks ago, though:

This is a preview feature, so if you use it in a single source-file program, where it clearly shines, you need to add --enable-preview --source 21 to the java command.
```
java --enable-preview --source 21 Hello.java
```
There are plans to shorten System.out.println to just println and also offer a more succinct way to read from the terminal, but neither of that is part of JDK 21.

Embedded video.

Unnamed Variables and Patterns

Unused variables are annoying but bearable. Unused patterns during deconstruction, on the other hand, are really cumbersome and clutter code - they make you want to deconstruct less.

String pageName = switch (page) {
	case ErrorPage(var url, var ex)
		-> "💥 ERROR: " + url.getHost();
	case ExternalPage(var url, var content)
		-> "💤 EXTERNAL: " + url.getHost();
	case GitHubIssuePage(var url, var content, var links, int issueNumber)
		-> "🐈 ISSUE #" + issueNumber;
	case GitHubPrPage(var url, var content, var links, int prNumber)
		-> "🐙 PR #" + prNumber;
};

So it's really good that JDK 21 turns the underscore into a special variable and pattern that says "I won't be used and you can have as many of me as you want in the same scope".

String pageName = switch (page) {
	case ErrorPage(var url, _)
		-> "💥 ERROR: " + url.getHost();
	case ExternalPage(var url, _)
		-> "💤 EXTERNAL: " + url.getHost();
	case GitHubIssuePage(_, _, _, int issueNumber)
		-> "🐈 ISSUE #" + issueNumber;
	case GitHubPrPage(_, _, _, int prNumber)
		-> "🐙 PR #" + prNumber;
};

That makes code more clearly readable and reduces IDE and compiler warnings. Best of all, though, it makes switching over sealed types more maintainable by allowing you to easily combine default-y handling of different types into a single branch while avoiding an outright default branch.

String pageEmoji = switch (page) {
	case GitHubIssuePage _ -> "🐈";
	case GitHubPrPage _ -> "🐙";
	// explicitly list remaining types to avoid default
	// branch (only possible with unnamed patterns)
	case ErrorPage _, ExternalPage _ -> "n.a.";
};

If you want to better understand why that's important and how exactly unnamed variables and patterns work, watch Inside Java Newscast #46.

Embedded video.

String Templates

Embedding variables or simple expressions in strings has a bad name. For one, it's a bit cumbersome and not perfectly readable. But more importantly, if the embedded content comes from the user, there's the risk of injection attacks. And generally, unless we're creating text for humans to read, there's probably syntax and escaping to consider.

// a cumbersome and dangerous example
String property = "last_name";
String value = "Doe";

String query = "SELECT * FROM Person p WHERE p."
	+ property + " = '" + value + "'";

String Templates solve all that in one go. Not only do they make it easy to embed expressions in string literals or text blocks by encasing them in an opening backslash, curly brace and a closing curly brace, they also enforce processing of such string templates by domain-specific string processors. Such processors receive the string portions and the variables separately and returns instances of any type. The obvious processor just concatenates and returns a String but there are other possibilities out there. An SQL processor could validate and parse a statement's syntax and return a java.sql.Statement and a JSON processor could return a JsonNode.

// a safe and readable example
String property = "last_name";
String value = "Doe";

Statement query = SQL."""
	SELECT * FROM Person p
	WHERE p.\{property} = '\{value}'
	""";

If you want to dig deeper, check out Inside Java Newscast #47.

Embedded video.

Outro

And that's it for today on the Inside Java Newscast. Another long one but I hope it was worth your time and that you're as excited about JDK 21 as I am. If so, you can do me a solid and like this video. But if you think it was too long or JDK 21 isn't that exciting after all, feel free to hit that dislike button twice. I'll see you again in two weeks. So long ...

Watch the video.

Script Java Easily in 21 and Beyond - Inside Java Newscast #49

Nicolai Parlog — Thu, 25 May 2023 00:00:00 GMT

To give Java and programming beginners a better learning path, JEP 445 proposes to allow stand-alone main methods that are non-public, non-static, and don't have an args array and we're also JEP draft for multi-file programs

Intro

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna look at how the smallest possible Java program will soon turn from "public class Hello public static void main String bracket bracket args" to, wait for it, "void main".

void main() {
	System.out.println("Hello, world!");
}

If you just had a deja vu, don't worry, your brain is fine (probably). The familiarity comes from me having said almost the exact same words back in October 2022 at the beginning of Newscast #35. Back then we already discussed why Java needs to be more beginner friendly, how a simple launch protocol with a gradual incline up to the highway of Java concepts would help, and what that could look like. And we're talking about it again today because of the one word I changed.

May soon turn from...
May soon...

Will soon turn...
Will soon...

Because in the last half year, the idea has matured and its core has made it into JDK Enhancement Proposal 445, which is targeted at JDK 21. Usually, I'd go over the whole JEP, including the motivation, but we already did all that in October, so I'm gonna spare you the repetition. If you didn't see that episode, I highly recommend you watch it right after this one, so you understand the context of this proposal. Today, I'll only cover the technical details. And because that won't make for a full episode, I'm gonna break the oath Mark Reinhold made me swear on a leather-bound printout of the JLS, and talk a bit about a related JEP draft that I find very exciting.

Ready? Then let's dive right in!

A Relaxed Launch Protocol

Visibility and instance vs static are proper programming concepts that help us structure large programs. For the simple scripts you'll typically find in a single source file, they're overkill, though, and come with a lot of baggage for a beginner to grok. The args argument array is more useful but also often not needed early on.

So JEP 445 proposes to no longer require public, static, and args for its main method. That means any or even all of those pieces can be absent and the launcher still identifies the method and executes the program. If the main method is not static, the launcher first creates an instance on which to call the method - this means the class needs the default or an explicit parameterless constructor. Consequently, the entry point gets simpler to "class Hello void main".

class Hello {

	void main() {
		System.out.println("Hello, World!");
	}

}

We could now go into the exact order in which the launcher will consider main methods on a class as the entry point, but this is only relevant if a source file has multiple main methods and I think we can all agree that that's confusing. So just don't do that - keep it simple and just have one main. The only noteworthy part of that is that a public static void main(args) method declared in the launched class or a superclass is considered first to guarantee backwards compatibility. And because a static main method in a superclass is a bit odd, we'll now get a warning for that.

The Unnamed Class

Another concept that is extremely useful in everyday programming but not yet when learning Java or putting together a small script is the class. In fact, in such situations the main class often only acts as a container of its methods and fields, similarly to how a package is a container of classes, and a module is a container of packages. And just like we have the unnamed module and the unnamed package for situations in which explicit and named modules or packages aren't yet needed, JEP 445 proposes the unnamed class.

It allows Java source files that contain methods, fields, and even inner classes as top-level elements, meaning they don't have to be wrapped in a class. (Imports are allowed, too, of course.) The compiler will then just wrap everything (except the imports) in an unnamed top-level class and from there on it's mostly business as usual. An unnamed class' members can have the same modifiers as regular class' members and the modifiers have the same defaults. And the class can have static and instance initializers. An unnamed class resides in the unnamed package and the unnamed package resides in the unnamed module - makes sense, right?

// all lines of Hello.java (i.e. no other code necessary)
import java.util.List;

String greeting = "Hello";
String audience = "World";

void main() {
	System.out.println(createGreeting());
}

String createGreeting() {
	// what's this? ~> IJN #47
	return STR."""
		\{greeting},
		\{audience}!
		""";
}

record NoReason(List<String> reasons) { }

That turns a simple Hello World into "void main" and off you go! I like that so much!

void main() {
	System.out.println("Hello, World!");
}

There are few noteworthy details, though, and I gotta admit that it's really impressive how they all naturally flow from a single property: Just like their unnamed module and package counterparts, unnamed classes can not be referenced by name. And this has a few purely syntactic consequences:

they can implement no interface and extend no class besides Object
no class can extend the unnamed class
they can define no constructors
no instances can be created explicitly

And those limitations make perfect sense for a simple program's entry point! Because that's what the unnamed class must be and so it must contain a suitable main method.

The On-Ramp

This proposal adds another section to the on-ramp from Java or even programming beginner to Java developer. I like to see the single-file source code execution, introduced in Java 11, as the mid-section of that ramp and the simplified launch protocol and unnamed class as parts of its early section. What I think is still missing here are simple ways to read from and write to the terminal (and yes, simpler than System.out.println) and an easy way to parse the argument array. Interaction with the terminal was mentioned by Brian Goetz' white paper last October, so I'm sure that is being considered.

Put all that together and you got a good way to start out with a simple main and then progress to more methods, Java APIs, external configuration via arguments, and eventually a full-blown class with inner classes - and you can take most of those steps in any order you want. What is still missing from that picture is the late section of the ramp, where you want to turn a single-file script into a small, local project with multiple files and maybe even third-party dependencies. And this is where the JEP draft comes in, link in the description of course.

It's called Launch Multi-File Source-Code Programs and proposes exactly that. It would expand the java launcher so that you could throw multiple source files and even JARs at it and it would compile the sources in memory and launch their main method. The source files could be in the unnamed package, but you can also create a package / directory hierarchy.

MyFirstJava
├─ app
|  └─ Prog.java
├─ util
|  └─ Helper.java
└─ Lib
	└─ library.jar

// Prog.java`:
package app;

import util.Helper;

class Prog {
	void main() {
		Helper.run();
	}
}

# run with
java -cp 'Lib/*' app/Prog.java

This takes you from single-file scripts to multiple files, then a package structure, and maybe even dependencies somewhere along the way. The point where this imagined on-ramp leads onto the Java highway is when you want to package your program in non-source form: To create a JAR, you'd need to leave java behind and switch to javac and jar, or better yet, a build tool. I think that's a very natural inflection point.

What's still missing, though, is a good way to get the dependencies. I mean, how do you download a JAR and its transitive dependencies without touching a build tool? Not easily, that's for sure! I'm curious to see whether this problem will be tackled and if so, how.

Outro

And that's it for today on the Inside Java Newscast. If you enjoyed the video, you can do me a favor and give it a like and if you're looking forward to Java 21, make sure to subscribe because then I'll see you in two weeks with a rundown of all its features - it's gonna be wild! Don't believe me? Here's a little preview.

(What's happening?)
(What's happening?)
WHAT'S HAPPENING?!

Watch the video.

Scaling Simply with Virtual Threads

Nicolai Parlog — Wed, 24 May 2023 00:00:00 GMT

Virtual threads combine the simplicity of blocking code with the resource efficiency and scalability of reactive programming and in this talk you're going to learn how they do that and how you can use them in your project

When every request coming into a system runs in its own thread but keeps blocking it for outgoing requests to the file system, databases, or other services, the number of threads the system supports quickly becomes the limiting factor for scaling up throughput. Reactive programming solves this problem by only occupying platform threads when they are actually needed, thus offering better scalability, but comes at a cost: developing, maintaining, debugging, observing, and benchmarking code becomes more challenging.

Save 10-20% Memory With Compact Headers - Inside Java Newscast #48

Nicolai Parlog — Thu, 11 May 2023 00:00:00 GMT

JDK Enhancement Proposal 450 proposes to merge a compressed class word into the mark word to reduce object header size on 64-but systems from 96-128 bits to 64 bits, thus saving 10-20% of heap space

Intro

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna see how Java may soon return 10% to 20% of your memory back to you. And in the process learn a lot about object headers and bit about garbage collection, concurrency, the type system, and hash codes, of all things.

Imagine your heap space: A big chunk of memory, usually in the gigabytes, that your instances live in. The strings and collections, the data-transfer objects and web services, the customers and orders, all of that. On many workloads, the average object size is 256 to 512 bits, or 32 to 64 bytes, or 4 to 8 words, but not all of that is your data. Usually 2 of each of those words are the so-called "object header" - that's between 20% and 40% of your heap!

What's an object header? Can't we make it smaller? Imagine how much memory that would save us.

And that's exactly what Project Lilliput, JDK Enhancement Proposal 450, and this Inside Java Newscast are all about. Ready? Then let's dive right in!

Object Headers

For any of this to make sense, we first need to establish what an object header is, how it's structured, and how the runtime and garbage collectors work with it. If you already know all this, you can safely skip ahead to the Compact Object Headers chapter. For the rest, settle in for a Lego-infused look under the runtime's hood.

On a 64-bit HotSpot JVM, the archetypical object header is 128 bits long and consists of two words: the mark word and the class word. The mark word contains three pieces of information:

31 bits for the object's stable identity hash code once it has been computed
4 bits that the garbage collector uses to mark an object's age
and 2 tag bits

The remaining 27 bits are unused but they can't be recovered because I've only told the simple half of the truth about mark words. In the other half they take on another form. For that, let's talk about locking and garbage collection.

Locking

When you write a synchronized block, the runtime ensures that only one thread grabs the associated object's monitor while contending threads wait.

private final Object lock = new Object();

public void execute() {
	// threads need to obtain the monitor
	// of `lock` to enter the block
	synchronized(lock) {
		// only one thread at a time will
		// ever be in this block
		executeNonConcurrently();
	}
}


private void executeNonConcurrently() {
	// ...
}

Did you ever wonder how that works? I did, but never enough to look it up but thanks to the excellently written JEP 450, I don't need to any more. When a thread obtains a monitor, it needs to mark its ownership and the light-weight mechanism for that is stack locking:

the original mark word is moved to the thread's stack (this is called displacement),
in the original location, the mark word's 62 non-tag bits are replaced with a pointer to that stack location
and the 2 tag bits are used to mark what's going on

While stack locking is light-weight, it suffers from race conditions. So when there's contention over the lock or when another thread needs to read the mark word, for example to get the identity hash code, the stack lock is inflated to the more heavy-weight monitor lock:

an ObjectMonitor structure is created
and the mark word is displaced there

So in both of these locking schemes, the mark word in the object header is now a tagged pointer that code that wants to access the object's identity hash code or GC age, needs to follow. And this displacement of the mark word becomes an issue with more compact headers as we'll see when we get to them.

Garbage Collection

But locking is not the only mechanism that replaces the mark word - garbage collectors do that, too. A big part of a garbage collector's work is figuring out which objects in the heap are still referenced (and hence needed; they're called alive) and which can be safely overwritten. We can ignore that part for another minute or so, but will get back to it when we come to the class word.

What we care about now is the part where the GC moves live objects around. It does so in two ways:

During a young collection, it copies an object to its new memory location and then replaces the mark word in the old version with a tagged pointer to the new location, so other GC code that still accesses the old copy knows where to find the new one. But in case this evacuation fails, a non-intuitive mechanism is used to mark the object until the problem is solved: Its mark word is replaced with its current address, thus making the object self-forwarded.
When memory is really tight, during a full collection, the GC compacts the heap by sliding all objects next to each other towards lower memory addresses. It computes the destination addresses for all live objects and in a sneaky optimization, most GCs keep track of the many new addresses by simply writing each to the original object's mark word. The GC then updates all references and finally copies all objects to their new locations.

At this point, you should be wondering what the heck is going on. How can the mark word be replaced with a tagged pointer to itself or to a future location. This loses the original mark word, right?

Yes, but it turns out that for most objects in that situation, the mark word doesn't actually contain interesting information. Most objects are neither locked nor has their identity hash code been computed. And age bits are only relevant during young collection: Objects that fail evacuation or survive full collection are always made old. So such mark words can simply be recreated in the new location after copying. The few interesting ones, for example of a locked object, are stored in a side table and recovered from there after copying.

So again, we have two cases where the mark word gets overwritten with a tagged pointer and we're getting closer to when we'll see why that is a problem. But first, deep breath! Ready for the class word?

(No, no, no, don't skip ahead. This is important and it'll be shorter.)

Class Word

The mark word is followed by the class word, which in its archetypical form is a 64-bit pointer to a data structure called klass (with a "k") that contains all kinds of meta-information about an object's type:

its field layout
its superclasses and interfaces
a pointer to the Class instance (with a "C" this time - the Java class)
and more

The class word is used quite frequently, for example for runtime type checks and reflection. The garbage collector is particularly interested in the field layout. It uses that to compute an object's size, which it needs to know when linearly scanning the heap or when sliding objects. And because the class word is never overwritten the parts of the runtime that need type information can be unaware of the mechanisms that we discussed earlier because they only change the mark word. I said that in the archetypical header form, mark word and class word are 64 bits each, but in most situations the JVM will set the option UseCompressedClassPointers, which halves the size of the class word to 32 bits. Which finally brings us to Project Lilliput and JDK Enhancement Proposal 450.

Compact Object Headers

JEP 450 proposes compact object headers as an experimental feature for the HotSpot JVM on x64 and ARM64. It will be turned off by default and can be turned on with the option UseCompactObjectHeaders. If activated, object header size will be reduced to 64 bits, which is achieved by removing the class word and stuffing the always-compressed class pointer into the mark word. To that end, the identity hash code needed to loose a few bits, so now we have:

32 bits for the compressed class pointer
25 bits for the identity hash code
4 GC bits
a new self-forwarded bit
and the 2 tag bits

Now, do you see why we talked about all the times the mark word is replaced with a tagged pointer? Since the mark word now includes the class pointer, the subsystems that need type information must follow that tagged pointer to recover the displaced mark word. That not only requires a lot of code changes within HotSpot, it also has correctness and performance implications for locking, garbage collection, and more. Let's go over these.

Locking

Remember that to guarantee correctness the light-weight stack lock is inflated to a heavy-weight monitor lock when there's concurrent access to the displaced mark word. That was fine when it could only be triggered by the relatively rare need to read or write the hash code but now that the class pointer is also displaced (and it's used very frequently), that would trigger the inflation of most locks, which would result in unacceptable performance overhead. That's why Project Lilliput is working on an alternative light-weight locking protocol that stores locking data in a separate thread-local area rather than by displacing the mark word, thus keeping the class pointer in the object header. There's a link to the issue tracking the work on this protocol in the description.

Garbage Collection

When walking over the heap, the GC needs to know an object's length, which it gets from the klass information, which it gets by accessing the class pointer. That's all good when the pointer is right there in the header, but when it's displaced, this incurs an additional dereference. While the cost of that can be significant, in practice it is rare to walk over locked or already-forwarded objects.

Ok, but what about the cases where the GC, in the process of moving objects around, overwrites the mark word with the object's current or future address? Because while an uncomputed hash code can be recreated later, the object's class pointer surely can't, and so all mark words are now interesting. That would mean storing them all in the side table but that would consume a significant amount of native heap memory.

Instead, in case of evacuation failure during young collection, where the mark word would be overwritten with the address to itself, JEP 450 proposes to set a dedicated self-forwarding header bit.
For sliding compaction during a full collection, Lilliput proposes to compress the forwarding pointer into the hash code field and in the rare cases where that is not possible, use a side table like ZGC does.

Hashing

Speaking of compression and hash codes... Having only 25 bits for the identity hash code doesn't impact their correctness, remember that all hash codes being 0 is technically allowed. But it may affect the performance of large hash tables that rely on higher identity hash code entropy. This will have to observed in practice.

The Compact Future

Project Lilliput is really exciting and it's great to see that JEP 450 is now out. But as you've seen throughout this Newscast, this change touches many HotSpot subsystems and such massive changes warrant massive testing. Lilliput is on it, though, and is battering their implementation with tests, benchmark suites, dedicated tools, and real-world workloads. Speaking of real-world workloads, early adopters who have run those on preview builds confirm that live data is typically reduced by 10%–20%.

And when can you start testing? I don't know whether JEP 450 will make it into 21 but I doubt it. But I hope for in integration later this year, so maybe JDK 22 EA builds in fall or winter?

As for Lilliput's future after that, there are ideas for how to shrink the number of class pointer bits to 22 and to have side tables for hash codes and the object-to-monitor mapping, thus reducing the object header size to 32 bits. Quote:

That is our ultimate goal, but initial explorations show that it will require much more work.

Outro

And that's it for today on the Inside Java Newscast. That was a long one, thank you for sticking with it. And since you made it all the way to the end, what about a like or a subscribe? Then I'll see you again in two weeks. So long...

Watch the video.

Getting Rid Of Unused Variables (Finally) - Inside Java Newscast #46

Nicolai Parlog — Thu, 13 Apr 2023 00:00:00 GMT

JEP 443 proposes to add unnamed variables and patterns to Java. With them, unused variables and patterns can be replaced by a single underscore, which helps writing readable and maintainable code.

Intro

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna get rid of all those variables you had to declare even though you didn't want to use them. No need for this first parameter of that lambda? Now it's gone! Don't care about the exception? Gone! No use for all those destructured record components? Guess what? Gone!

IntStream numbers = // ...
int someLargeNumber = numbers
	.reduce((💥, num) -> num > MAX_VALUE / 2 ? num : 0);


try {
	// ...
} catch (IOException 💥) {
	System.err.println("That didn't work. 🤷");
}


if (shape instanceof Triangle(var a, 💥, 💥))
	System.out.println("Triangle point A: " + a);

Because today we're gonna talk about JEP 443: unnamed patterns and variables. They're mainly about convenience and clarity, and we'll go over that first, but you'll also see why they will play a critical role in writing maintainable pattern matches.

Ready? Then let's dive right in!

Unused

The Situation

Unused variables are pretty annoying: IDEs turn them grey or give you squiggly lines, code linters give you stink eye, and your colleagues are tattling about yours behind your back. And they all have good reason! Until they don't. Because sometimes it just can't be helped.

Maybe you're implementing a BinaryOperator but only need the second argument. Maybe your error handling doesn't depend on the specific exception you're catching. Maybe the resource in your try-with-resources block only needs to be opened and closed but you don't want to interact with it. Then there's the rare for-each loop where you don't actually need the loop variable. And in even rarer cases you may want to capture a method's return value even though you don't want to use it.

These situations are pretty uncommon (although the unused lambda parameter pops up a bit more often in my code) but if you've already experimented with record patterns, you know that not needing all the destructured components is actually pretty common. And deconstruction itself will become more common. At the moment, it only works with records in pattern matching but both of those limitations may be relaxed in the future: Classes in general may get explicit deconstructors and deconstruction on assignment and in for each loops is also on the horizon.

// made up syntax!     ↓↓↓↓↓ unused
Triangle(var a, var b, var c) = fetchTriangle();
System.out.println("A & B: " + a + " & " + b);

Collection<Triangle> triangles = // ...
// more made up syntax!     ↓↓↓↓↓ unused
for (Triangle(var a, var b, var c) : triangles)
	System.out.println("A & B: " + a + " & " + b);

So the future brings more deconstruction, which will bring more unused variables.

The Workarounds

But what can you do if you want or - more likely - need to declare a variable that you're not going to use? Some devs give the variable a regular name and simply ignore it. Others punish it by cutting its name short to a single letter - no self-documenting name for you! You could name it unused. But none of these are ideal.

(result, number) -> number > 1_000 ? number : 0
(     r, number) -> number > 1_000 ? number : 0
(unused, number) -> number > 1_000 ? number : 0

Here's what I do: Java 8 deprecated the use of the single underscore for variable names and Java 9 forbade it - it's been a compile error ever since.

//   legal in Java 7-
// warning in Java 8
//   error in Java 9+
int _ = 0;

So I use the double underscore for such variables.

(__, number) -> number > 1_000 ? number : 0

Until I need two of them in the same scope - then I have to up it to three. But that doesn't keep the IDEs and linters from complaining either.

So, all in all, not a great situation. It hasn't been a big problem in the past but with deconstruction patterns becoming more common, it will become very annoying very quickly. So somebody needs to do something about it!

Unnamed

The Solution

Thankfully the good people working on Project Amber are on it! I just said that Java 8 deprecated and Java 9 forbade the use of the single underscore, right? That happened for exactly this scenario! (Which is where I got the idea to use two underscores from. Yeah, I'm not very creative.)

So Project Amber brought forth JDK Enhancement Proposal 443: unnamed patterns and variables. In a nutshell, you can use the single underscore in place of a variable name or a pattern but you can never refer to it - you can't "declare" String _ and then call _.length(). And because _ does not actually refer to a variable, you can use it several times in the same scope. If you don't need that lambda parameter nor that exception nor those two record components, you can use _ for all of them!

try {
	// something
} catch (IOException _ ) {
	Stream<Shape> shapes = // ...
	return shapes.reduce(( _ , shape) -> {
		if (shape instanceof Triangle(var a,   _  ,   _  ))
			return a;
		else
			return shape.center();
	});
}

Marking unused variables this way has a number of benefits: The most obvious one is that we no longer have to come up with names for them. (I can already feel the stress falling away.) Then it removes visual clutter and clearly communicates to your colleagues that the variable is unused. The same is true for compiler and linters, so we can expect fewer warnings from them. And then there's the pattern matching bonus that I mentioned in the intro but before we get to that I want to go over a few details of the proposal.

The Details

Technically, the proposal consists of three parts:

unnamed variables
unnamed variables in patterns
unnamed patterns

Let's take it one by one. Unnamed variables replace the variable name in

a local variable declaration
a resource specification of a try-with-resources statement
the header of a basic or enhanced for loop
an exception parameter of a catch block
a formal parameter of a lambda expression

If you want, you can use unnamed variables with var and just like there, there must always be an initializer, for example an expression on the right-hand side of a local variable declaration. Declaring an unnamed variable does not place a name in scope, which are fancy words for it can't be written or read after it has been initialized. And since nothing is placed in scope, there's no shadowing and you can declare multiple such variables.

Unnamed pattern variables replace the variable name in, wait for it, patterns. Namely, in type and record patterns, because that's all we have at the moment. They do require explicit types, though.

If you want to get rid of the type information, too, basically writing var _, you have an unnamed pattern and don't the need the var after all - just replace the full type-and-variable-name with _. Unnamed patterns bind nothing but match everything, which is why they don't make sense at the top level and so are forbidden there: They can only be used in nested positions in place of a type or record pattern.

Patterns

I mentioned that this will play a critical role in writing maintainable pattern matches. In particular, I was referring to unnamed patterns in switches because they make it more convenient to avoid default branches.

Now, why would you want to do that? In order to implement behavior that differs by type, you want to switch over a sealed supertype and then exhaustively and explicitly list all possible subtypes.

sealed interface Shape
	permits Triangle, Rectangle, Circle { }

var shape = // ...
switch (shape) {
	case Circle c -> highlight(c);
	case Triangle t -> { }
	case Rectangle r -> { }
}

That way, when a new subtype gets added, you can follow the compile errors to all the switches that need to be updated.

sealed interface Shape
	permits Triangle, Rectangle, Circle, Line { }

var shape = // ...
switch (shape) {
	case Circle c -> highlight(c);
	case Triangle t -> { }
	case Rectangle r -> { }
	// no `Line` branch ⇝ compile error
}

Now, if you'd have used a default branch, the switch would still be exhaustive and you wouldn't get a compile error - the code would silently run into that branch whether that's correct or not.

sealed interface Shape
	permits Triangle, Rectangle, Circle, Line { }

var shape = // ...
switch (shape) {
	case Circle c -> highlight(c);
	default -> { }
	// default for `Line` ⇝ no error
	// but is it the correct behavior? 🤷
}

Ok, so we need to avoid default branches by explicitly listing all possible subtypes. But sometimes you just have "defaulty" behavior for a few of those branches and so you want to combine them. But while multiple case labels are legal since Java 14, multiple named patterns are not. Because case Triangle t, Rectangle r doesn't make any sense - you could use neither t nor r because the compiler doesn't know which one matched.

sealed interface Shape
	permits Triangle, Rectangle, Circle { }

var shape = // ...
switch (shape) {
	case Circle c -> highlight(c);
	// compile error
	case Triangle t, Rectangle r -> { }
}

And this is where unnamed patterns come in! With them, you can use multiple unnamed patterns in a single case label: case Triangle _, Rectangle _. You still don't know which pattern matched, but since you can't refer to any variable anyway, that doesn't matter.

sealed interface Shape
	permits Triangle, Rectangle, Circle { }

var shape = // ...
switch (shape) {
	case Circle c -> highlight(c);
	// simple default behavior 🥳 plus
	// compile error when adding `Line`
	case Triangle _, Rectangle _ -> { }
}

So here's my recommendation for switches over a sealed supertype:

handle all subtypes explicitly
do not use a default branch
if you have default behavior, use multiple unnamed patterns in a single case to match the relevant subtypes

This way, you have just a bit more code than with a default branch but in return the compiler will point you to this switch if you add a new subtype. To me, beyond the convenience and clarity JEP 443 will doubtlessly bring to our code, this is the biggest benefit because it really helps write more maintainable code. When we'll start doing that is not settled, though - the JEP is not yet targeted to a release.

(By the way, have you noticed that we've moved past the must-have list of pattern matching features and got to the nice-to-haves? Yeah, Java has pattern matching now. Incredible.)

Outro

And that's it for today on the Inside Java Newscast. If you like these videos, do me a favor and let YouTube know. In two weeks, Ana will tell you all about the biggest improvement Java's strings have ever seen - yes, bigger even than text blocks. Subscribe and ring the bell, so you won't miss it. I'll see you again in four weeks. So long...

Watch the video.

New (Sequenced) Collections In Java 21 - Inside Java Newscast #45

Nicolai Parlog — Thu, 30 Mar 2023 00:00:00 GMT

All lists, some sets, and some maps have an encounter order, but the collections framework has no type to capture this property and define operations like getting or removing first and last elements or iterating in reverse order. Sequenced collections will fix that in Java 21.

Intro

Welcome everyone, to my new studio - to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna see how Java 21 will make it super easy to get the last List element or the first LinkedHashSet entry, to loop and stream over a reversed list or set, and generally how to better exploit what the Java collection framework calls encounter order. Yes, we'll talk about JEP 431: Sequenced Collections.

But before we get into that: If you have any questions about this, I'll do a live Q&A with the JEP owner and Java collection guru Stuart Marks tomorrow, Friday 31st, at 1900 UTC on twitch.tv/nipafx. And if you missed that, head over to inside.java/podcast and subscribe on your favorite platform - there will soon be an episode with the same Stuart on the same topic.

Ready? Then let's dive right in!

Sequenced Types and Methods

Java gets three new interfaces:

SequencedCollection, which extends Collection and is further extended by List and Deque. Or Deck? Let's go with Deque. It offers methods addFirst/addLast, getFirst/getLast, and removeFirst/removeLast, which do what you'd expect. It also has a method reversed that returns a SequencedCollection that is a view on the underlying collection but in reverse order.
SequencedSet, which extends SequencedCollection and Set and is further extended by SortedSet and implemented by LinkedHashSet. It offers no additional methods but defines a covariant override of reversed that returns a SequencedSet.
SequencedMap, which extends Map and is further extended by SortedMap and implemented by LinkedHasMap. It offers methods putFirst/putLast, firstEntry/lastEntry, and pollFirstEntry/pollLastEntry. It also has a method reversed that works analogue to the one on SequenceCollection. Furthermore, it offers sequenced views of its key set, values, and entry set.

And that's it for today on the Inside Java Newsc... wait, why are you all still here? You usually leave right when the outro begins (and miss all the cool stuff therein, I want to add). You want more on sequenced collections? There are lots of more interesting details in the JEP, so I'm all for it! We can start by establishing the problems this actually solves, see a few examples, and discuss a few odds and ends.

Let me just... there we go.

The Problem

The Java collection framework has the concept of encounter order, which means that there's a well-defined order to the elements in the collection and iteration will always visit them in that very order. This is obviously true for everything that's sorted, but order, or sequence as I'll start to call it for mysterious reasons, is weaker than that. Even unsorted elements in a list, for example, are sequenced because each element has a well-defined position in that list. So all lists are sequenced.

A classic example of a non-sequenced collection, one without encounter order, is a set. At least generally, because there are Set implementations, that do have a sequence: not only the SortedSet implementations, but also the class LinkedHashSet.

And here we can already see one half of the issue with encounter order. While well defined, that's only in prose - there's no type that guarantees this property across all these different collections. The other half is that sequence-related operations are very inconsistent.

Need the first element of a list? list.get(0) is there for you. Already somewhat imprecise but wait till you try to get the last element. Few things in Java have been as bad for my teeth as typing out list.get(list.size() - 1). Ugh!

Things are even worse for LinkedHashSet, though. Getting the first element requires us to either ask the iterator for the next element or findFirst() on a stream and getting the last element isn't even possible without iteration.

// getting first/last element on...

// ... `List`:
var first = list.get(0); 😐
var last = list.get(list.size()-1); // 😬

// ... `LinkedHashSet`:
var first = set.iterator().next();
first = set.stream().findFirst();
var last = 🤷

Side note: I also sometimes want to get just any element from a Set, which forces me to go through the same iterator() or stream() methods. Would be nice to have a getAny() or something like that on Set. Maybe I'll ask Stuart about that.

Finally, iterating in reverse order is pretty annoying as well and streaming that way, my preferred way to process collections, is hardly supported at all. So while collections have the concept of encounter order, of a sequence, they don't have a type to capture that and so no place to uniformly define operations like getting the first and last elements or reversing the sequence. Until JDK 21 that is.

// iterating in reverse order over ...

// ... `List`:
for (var it = list.listIterator(list.size());
		it.hasPrevious();) {
	var e = it.previous();
    // use `e`
}

// ... `Deque`:
for (var it = deque.descendingIterator();
		it.hasNext();) {
    var e = it.next();
    // use `e`
}

// ... `NavigableSet`:
for (var e : navSet.descendingSet()) {
	// use `e`
}

// streaming in reverse order over ...
// ... `List`: 🤷
// ... `Deque`: 🤷
// ... `NavigableSet`:
navSet.descendingSet().stream()

A Deeper Look At The Solution

After mysteriously calling encounter order "sequence", let me now reveal to you the surprising reason: The new collection interfaces are called "sequenced" - as in "the elements have been arranged in a sequence". A sequenced collection has first and last elements, and the elements between them have successors and predecessors. It further supports common operations at either end and it supports processing the elements from first to last and from last to first.

I already listed the interfaces and their methods, so let's see how to use them in practice. Which is super straight-forward. First and last elements of all lists, sorted sets, LinkedHashSets and whatever else implements SequencedCollection or SequencedSet are available with getFirst and getLast.

// getting first and last elements from a list
// (sequenced by order of addition)
var letters = List.of("c", "b", "a");
"c".equals(letters.getFirst());
"a".equals(letters.getLast());

// same but from a sorted set
// (sequenced by natural ordering)
var letterSet = new TreeSet<>(letters);
"a".equals(letters.getFirst());
"c".equals(letters.getLast());

You can also add or remove at both ends of the collection, but those methods may throw an UnsupportedOperationException. The obvious case where that happens is when the underlying collection is unmodifiable. The more subtle case is trying to add a first or last element to a sorted collection when it doesn't belong in that place. Clearly, being sorted overrides the desire to add at specific positions and so an exception is thrown here as well.

var letters = new ArrayList<>(List.of("c", "b", "a"));
letters.addFirst("x");
// ~> ["x", "c", "b", "a" ]

var letterList = List.of("c", "b", "a");
letterList.addFirst("x");
// ~> UnsupportedOperationException
// (`letterList` is unmodifiable)

var letterSet = new TreeSet<>(letters);
letterSet.addFirst("x");
// ~> UnsupportedOperationException
// ("x" does not belong in first position)

I gotta say, the SequencedMap API strikes me as a bit odd. It has adopted the NavigableMap nomenclature, so instead of getFirstEntry it's firstEntry and instead of removeLastEntry it's pollLastEntry. Not a big fan, but having names more in line with SequencedCollection would mean NavigableMap gets four new methods that do the same as four other methods it already has.

Further warts are added by not being able to restrict the return type of keySet() from Set to SequencedSet. Because the new interfaces are retrofitted into the existing hierarchy (by implementing all the new methods with default methods, btw - Java 8 for the win!) every implementation of a SortedMap is now also an implementation of SequencedMap. That includes lots of sorted maps outside of the JDK and if keySet() would now demand to return a SequencedSet, they would neither compile nor run. That's a no go. So instead of changing the return type for keySet(), a new default method sequencedKeySet() is being added. Not great, but what are you gonna do?

One deceptively simple method on the new interfaces is reversed. It returns a potentially writable view, which means it's very cheap and it always reflects the same state as the underlying collection, so changing one will change the other.

var letters = new ArrayList<>(List.of("a", "b", "c"));
var reversedLetters = letters.reversed();

letters.addLast("d");
reversedLetters.forEach(System.out::print);
// ~> dcba

reversedLetters.addFirst("e");
letters.forEach(System.out::print);
// ~> abcde

It also immediately unlocks all iteration methods! Whether you want to use a for-each loop or the forEach method, an explicit iterator or a stream, they are all uniformly supported out of the box. And a reversed array becomes as easy as collection.reverse().toArray(). Very neat!

for (E el : list.reversed())
	// ...

deque.reversed().forEach(/* ... */);

set.reversed().stream().//...

var reversedArray =
	list.reversed().toArray();

Overall, this is a great addition! Not headline grabbing but exactly the thoughtful evolution that Java needs.

Outro

And that's it for today on the Inside Java Newscast - this time for real. Do all the YouTube things, share this video with your friends and enemies, and don't forget to stop by twitch.tv/nipafx on Friday 1900 UTC for a conversation with Stuart Marks or to look out for the Inside Java Podcast episode with him. I'll see you again in two weeks. So long...

Watch the video.

Java 20 🥱

Nicolai Parlog — Tue, 14 Mar 2023 00:00:00 GMT

The list of big new features that can be used in production with Java 20 is rather short: . (That was it already.) Pretty boring, these six-month releases. We really don't need to take a closer look ...

We really don't need to take a closer look at Java 20, because there are just a few improvements to security and performance. And to observability and tools. Oh, and to regular expressions and Unicode. And the previews of virtual threads, structured concurrency, pattern matching, and the new foreign APIs for interacting with native code and off-heap memory have progressed as well. And let's not forget the new scoped values API, which partially replaces thread locals and interacts better with virtual threads - it just started incubating in Java 20.

Hm. Maybe it's worth taking a closer look after all.

Maybe it's worth taking a closer look after all

So let's get to it. First the obligatory part (finalized improvements in security, performance, observability, tools and more), then the fun part (updated previews of foreign APIs, pattern matching, virtual threads, and structured concurrency plus new scoped values API). Finally, I'll briefly talk about obstacles when updating to Java 20.

Security

Like every release, Java 20 adapts Java to the constantly evolving security landscape. DTLS 1.0 was disabled by default because the IETF depredated this version for lack of support for strong cipher suites. The remaining TLS_ECDH_ cipher suites have been disabled as well because they do not preserve forward secrecy. None of these algorithms should be used in practice, but you absolutely need to, you can enable them at your own risk with the security property jdk.tls.disabledAlgorithms.

The class javax.net.ssl.SSLParameters got two new methods getNamedGroups() and setNamedGroups(), which let you inspect and configure the key exchange algorithms used when creating a (D)TLS connection.

If you're using JNDI with LDAP or RMI, check out the new security properties jdk.jndi.ldap.object.factoriesFilter and jdk.jndi.rmi.object.factoriesFilter. They configure which classes are allowed to instantiate Java objects from JNDI/LDAP and JNDI/RMI contexts, respectively. If you have previously used your own object factories for this, you must now explicitly allow them with these properties.

For more information on security improvements in Java 19 and 20, I recommend Ana's Inside Java Newscast #42: From Java Security With Love.

Embedded video.

Performance

Just like with security, Java's excellent performance rests not only on good fundamentals but also on constant improvements from one release to the next. In this respect, Java 20's steps in these areas are certainly unspectacular when viewed individually but in the overall context exactly what Java needs: steady progress.

Steady progress

More Intrinsic Hash Functions

Java source code is converted to bytecode by the compiler and then, if necessary, translated into platform-specific machine code (and optimized in the process) by the just-in-time (JIT) compiler. However, a clever programmer can often write even more performant native code, which is done for methods that are particularly relevant to run time. Such platform-specific code is then stored as a so-called intrinsic function and can be used by the JIT compiler.

In Java 20, intrinsic implementations of the Poly1305 family hash functions have been added for x86_64 platforms. These implementations use the AVX512 extended vector instruction set, making them faster and more energy efficient. Intrinsic functions for the x86_64 and aarch64 platforms were also created for the ChaCha20 encryption algorithm.

G1 Improvements

A major refactoring of concurrent refinement thread handling in G1 should reduce the activity spikes of these threads and handle write barriers more efficiently. As a result, the following options no longer have meaning - they generate warnings and will be removed in a future release:

-XX:-G1UseAdaptiveConcRefinement
-XX:G1ConcRefinementGreenZone=buffer-count
-XX:G1ConcRefinementYellowZone=buffer-count
-XX:G1ConcRefinementRedZone=buffer-count
-XX:G1ConcRefinementThresholdStep=buffer-count
-XX:G1ConcRefinementServiceIntervalMillis=msec

G1's preventive garbage collections, introduced in Java 17, were intended to avoid expensive evacuation failures due to abrupt mass allocations. However, they themselves create additional work and it has been found that in most practical cases they do more harm than good to performance. In Java 20, they are disabled by default and can be re-enabled with -XX:+UnlockDiagnosticVMOptions -XX:+G1UsePreventiveGC.

Observability With JFR And JMX

A central property of the JVM and a major strength of its ecosystem is the runtime's transparency. Hardly any other platform can be observed and analyzed in such detail and with such little overhead. An essential tool for this is the Java Flight Recorder (JFR), a profiler with deep insight into the JVM and low overhead (with default settings less than 1% for long-lived applications). If you don't know JFR, you should definitely read up on it - Billy published a good tutorial on the Java YouTube channel.

Embedded video.

Starting with Java 20, JFR fires two new events:

jdk.InitialSecurityProperty reports the initial configuration loaded by java.security.Security (enabled by default)
jdk.SecurityProviderService reports details of calls to java.security.Provider.getService(String type, String algorithm) (disabled by default)

Something has also happened for JMX: The G1 Garbage Collector got the GarbageCollectorMXBean, which reports the occurrence and duration of remark and cleanup pauses.

Compiler And jmod

The compiler tries to protect us from all sorts of errors, for example when we mix up numeric types. The Java Language Specification (JLS) dictates that for assignments the numeric types on both sides must be assignemnt compatible. For example, double and long are not:

// Error - incompatible types:
// possible lossy conversion from double to long
long a = 1L + 0.1 * 3L;

In the case of compound assignments, however, a cast is inserted, i.e. these statements compile:

long a = 1L;
a += 0.1 * 3L;

While each specification makes sense in its context, the inconsistency is annoying. Java 20 mitigates this by letting the compiler emit a warning for the second variant when the new linter option lossy-conversions is enabled:

warning: [lossy-conversions] implicit cast from double
to long in compound assignment is possibly lossy
                 a += 0.1 * 3L;
                          ^
1 warning

Those who use the jmod command line tool to create JMOD archives will be pleased to know that the --compress option has been added. It accepts as value zip-$N where $N is a numeric value between 0 and 9 - 0 means no compression, 9 means strongest ZIP compression (default is zip-6).

Miscellaneous

Here are three more changes that don't fit into any of the other categories.

Named Group In Regular Expressions

Regular expressions aren't exactly known for their readability. You can improve this a bit by giving groups names:

var noNameMatcher = Pattern.compile("(\\d{4})-(\\d{2})-(\\d{2})");
var namingMatcher = Pattern.compile("(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})");

Not only is the regular expression itself more self-explanatory with group names, you can later query the groups not only via index (e.g. matcher.group(2)) but also via their name (matcher.group("month")), which is much more readable. All this has been possible since Java 1.7.

New in Java 20 is better support for groups with names. First, Matcher and Pattern now provide a mapping of group names to their indices with the namedGroups() method. Then, the MatchResult interface, which Matcher implements, has been extended by some of Matchers group-name related methods (by default implementation):

end(String groupName)
group(String groupName)
namedGroups()
start(String groupName)

In other news, Matcher and MatchResult acquired the new method hasMatch(), which indicates whether there's currently a match - basically, it returns the same as the last find() call but without changing the matcher's state.

Idle HTTP Connection Timeouts

The default timeout for idle HTTP/1.1 and HTTP/2 connections has been reduced - see Migration Challenges for more information. Starting with Java 20, the timeouts can be configured globally via system properties:

jdk.httpclient.keepalivetimeout sets the timeouts for HTTP/1.1 and HTTP/2 (in seconds)
jdk.httpclient.keepalivetimeout.h2 sets the timeouts for HTTP/2 (in seconds)

Unicode 15.0

Java 20 supports Unicode 15.0. That means 4,489 new characters for java.lang.character, bringing the total to 149,186. Java has character! (Sorry.)

Java has character!

From dealing with native code to pattern matching, from scalability to maintainability with virtual threads - Java is previewing solutions to some complicated challenges. Unfortunately, there is not enough space here to discuss the problems and their solutions in detail, which is why both are only summarized. In each section, however, the latest JEP for each proposal is linked and the changes in Java 20 are summarized.

Foreign Function & Memory API

Calling native code from Java is not that easy: The Java Native Interface (JNI) requires a number of artifacts and often non-trivial tool chains are used to create them. Especially when the native API is developing rapidly, adapting it for Java can be very tedious. And then there's memory management. Because passing Java objects with JNI is slow, many developers use Unsafe to allocate off-heap memory and then just pass the memory address. Of course, this makes the Java code very fragile.

The Foreign Function API and the Foreign Memory API (collectively FFM APIs) came about to solve these problems. Calls into native code are implemented by method handles (introduced in Java 7), which makes interaction with it much easier. For this purpose the classes Linker, FunctionDescriptor and SymbolLookup as well as the tool jextract (which lives outside the JDK) were introduced. Management of off-heap memory is represented by another set of new types:

MemorySegment and SegmentAllocator to allocate memory
MemoryLayout and VarHandle to access them in a structured way
SegmentScope and Arena to control (de)allocation

Taken together, this can look like the following example, where an array of Java strings is sorted using the C function radixsort:

// 1. find foreign function on the C library path
Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle radixsort = linker
	.downcallHandle(stdlib.find("radixsort"), ...);

// 2. allocate on-heap memory to store four strings
String[] words = { "mouse", "cat", "dog", "car" };

// 3. use try-with-resources to manage the lifetime of off-heap memory
try (Arena offHeap = Arena.openConfined()) {
	// 4. allocate a region of off-heap memory to store four pointers
	MemorySegment pointers = offHeap
		.allocateArray(ValueLayout.ADDRESS, words.length);
	// 5. copy the strings from on-heap to off-heap
	for (int i = 0; i < words.length; i++) {
		MemorySegment cString = offHeap.allocateUtf8String(words[i]);
		pointers.setAtIndex(ValueLayout.ADDRESS, i, cString);
	}

	// 6. sort the off-heap data by calling the foreign function
	radixsort.invoke(pointers, words.length, MemorySegment.NULL, '\0');

	// 7. copy the (reordered) strings from off-heap to on-heap
	for (int i = 0; i < words.length; i++) {
		MemorySegment cString = pointers
			.getAtIndex(ValueLayout.ADDRESS, i);
		words[i] = cString.getUtf8String(0);
	}

// 8. all off-heap memory is deallocated at the end of the
//    try-with-resources block
}

For more advanced experiments with the Foreign Memory API, I recommend Per Minborg's articles Colossal Sparse Memory Segments and An Almost Infinite Memory Segment Allocator.

The FFM APIs incubated for a few releases and see their second preview in Java 20. The implementation is very stable, but there are some surface-level changes to the API over Java 19:

The Arena and SegmentScope types have evolved from the removed MemorySession.
MemorySegment has incorporated MemoryAddress.
Improved sealed inheritance hierarchy of MemoryLayout for better interaction with pattern matching.

Speaking of pattern matching...

Pattern Matching

In Java, polymorphism (i.e. behavior that differs by type) is primarily implemented by overriding methods within an inheritance hierarchy. The Collection interface defines the add method and each collection - from ArrayList to HashSet - implements it according to its internal data structure.

However, sometimes it is undesirable or even impossible to implement new functionality as a method in an inheritance hierarchy. Whether that's because you don't want to overload core domain types with too many responsibilities or because the types in question aren't under your own control, there are situations where you have to implement polymorphism "from the outside". The design pattern for this is the visitor pattern, but that doesn't exactly impress with simplicity and readability.

Java is developing a better alternative to this, or more generally to the need to split program flow by types and object properties. For example, if you don't want to implement the computation of an area of a Shape as a Shape::area method, but "from the outside", you can do it like this:

static double area(Shape shape) {
	return switch (shape) {
		case Circle(var radius) -> radius * radius * Math.PI;
		case Rectangle(var width, var height) -> width * height;
	};
}

A few things stand out:

First of all, the switch that applies pattern matching to objects. Type patterns have been supported in instanceof since Java 16 and in Java 20 there is the fourth preview for it in switch.
These are not actually types patterns but record patterns, which are in their second preview. They allow records to be broken down into their constituent components.
Finally, notice that the switch is undefined for Shape instances that are neither a Circle nor a Rectangle. This is possible if Shape is a sealed interface, which only allows these two classes as implementations.

In order for the switch to work like this, Shape, Circle and Rectangle must be defined as follows:

sealed interface Shape permits Circle, Rectangle { }
record Circle(double radius) implements Shape { }
record Rectangle(double width, double height) implements Shape { }

In Java 20, these two preview features were polished around the edges:

If by extending a sealed type a switch is no longer exhaustive (e.g. by adding Triangle extends Shape to the above example) and this is not caught by the compiler (because the switch is not compiled together with Shape), a MatchException will now be thrown instead of an IncompatibleClassChangeError.
Generic type inference works (better) in switch and record patterns, so fewer parametric types need to be present in the code.

Record Patterns can also be used in loops:

List<Circle> circles = // ...
for (Circle(var radius) : circles)
	// use `radius`

For the time being, named patterns are out, i.e. while in Java 19 you could write case Circle(var r) c to also declare the variable Circle c, this is no longer possible in Java 20 because it has led to an ambiguous grammar.

So there's still some movement in these proposals, but I hope that at least pattern matching in switch is now at a point where there doesn't need to be another (fifth!) preview. This would have the pleasant side effect that the feature will be finalized and then usable in practice in Java 21 - the next LTS version.

Virtual Threads

Code that blocks an operating system (OS) thread while waiting for requests to external systems (e.g. the file system or the database) to return is easy to write, debug, and profile, but by not letting that OS thread do other things in the meantime it is wasting a limited resources. Depending on the application's load profile, this resource can become the constraining factor for scaling and the only reason for starting another server is not that the others have run out of CPU time or memory for Java objects, but out of OS threads.

You can replace this evil with another and implement the application reactively. For this purpose, you'd make extensive use of types like CompletableFuture or of reactive streams, such as those provided by RxJava. Then your app only uses OS threads when they are really needed - otherwise it waits (almost) for free. This makes the code much more scalable, but also more difficult to write and, in particular, more confusing to debug and profile.

Virtual threads combine the best qualities of these two approaches: You can use them to write, debug, and profile blocking code as usual, while under the hood the JVM ensures that the virtual thread running your code only occupies an OS thread when it actually needs it and not when it is waiting for an external system. (While it's waiting, the OS thread can execute another virtual thread.) So you can have orders of magnitude more virtual than OS threads and even a laptop can keep millions of virtual threads waiting without problems.

Virtual threads combine the best qualities of these two approaches

Java 19 introduced virtual threads as a preview feature and Java 20 gives them a second round of review. There are almost no changes compared to Java 19 - only a few small extensions of existing APIs (such as new methods on Thread and Future) are no longer part of the preview because they are useful independent of virtual threads and have been finalized in Java 20.

// finalized methods on `Thread`:
boolean join(Duration);
static void sleep(Duration);
long threadId();

// finalized methods on `Future`
V resultNow();
Throwable exceptionNow();
Future.State state();

// finalized new type
enum Future.State {
	CANCELLED, FAILED, RUNNING, SUCCESS
}

// finalized new type relationship
interface ExecutorService extends AutoCloseable

API extensions to create virtual threads are also part of this preview, but these won't play a major role in your day-to-day life:

In web applications, the app server or the web framework creates the threads that execute each web request. In order for these to be virtual threads, the servers/frameworks have to be updated and we developers will probably simply activate them via configuration.
For concurrency within the application, e.g. when sending requests to external services, it is better to use the structured variant. And we'll look into that next.

Structured Concurrency

Because virtual threads are so resource-friendly, you don't have to worry about when and where in the code they are created. On the contrary, it's perfectly fine to start virtual threads at every point where tasks should be performed concurrently.

In order for this type of concurrency to remain readable, Java recommends implementing it in a structured manner and letting (virtual) threads start, wait, and end in the same scope. A new API was incubated for this in Java 19: the StructuredTaskScope. Here is an example usage where a series of tasks (in the form of Callable<T>) should be executed but after successful completion of the quickest the others can be canceled and there is a deadline at which all to be are canceled:

public <T> T race(List<Callable<T>> tasks, Instant deadline)
		throws ExecutionException {
	try (var scope = new StructuredTaskScope.ShutdownOnSuccess<T>()) {
		// launch each task (implicitly in one virtual thread per task)
		for (var task : tasks)
			scope.fork(task);

		// wait for tasks to finish
		scope.joinUntil(deadline);

		// return the single result
		// (throws if no fork completed successfully)
		return scope.result();
	}
}

In this example shows two strengths of this API:

Concurrency is limited to one method and is thus easier to understand and predict.
Coordinating tasks (in this example "Shutdown on Success" but there are other strategies) is easy.

Not quite as obvious, but extremely helpful for debugging and profiling is the parent-child relationship that is implicitly established between threads. A thread executes the race method and waits in joinUntil while the forks it creates complete their respective tasks. During this time, the waiting thread is the parent and the forks are its children. This is not only a conceptual interpretation, but is also understood by the JVM because the StructuredTaskScope ensures that the child threads know the ID of the parent thread.

In practical terms, this means that in a breakpoint or thread dump you not only see each thread's stack, but can also navigate to the parent threads and their ancestors via the parent-child relationship. For example, if one of the tasks in the example above is in a breakpoint, you can see that it is the child of the thread that is currently waiting in race and also analyze its state. This will be a huge improvement for debugging and profiling concurrent applications, which so far often end up in the uninformative stack elements of a thread pool.

In Java 20, StructuredTaskScope was not changed.

Scoped Values

An API that correctly interacts with virtual threads, but is neither particularly efficiently nor resource-efficiently, is thread locals. They are used to store thread-specific information, usually in static final variables, which can then be queried from anywhere that variable is visible. In the following example, the Server::serve method is responsible for forwarding a request to the application, but first puts a Principal in a ThreadLocal so that other code that sees Server can use the principal (without passing it as a parameter):

class Server {

	final static ThreadLocal<Principal> PRINCIPAL = new ThreadLocal<>();

	void serve(Request request, Response response) {
		var level = (request.isAuthorized() ? ADMIN : GUEST);
		var principal = new Principal(level);
		PRINCIPAL.set(principal);
		Application.handle(request, response);
	}

}

ThreadLocal has a few shortcomings:

Anyone with access to PRINCIPAL can not only read the Principal but also set a new one.
Values stored in ThreadLocal can be inherited from one thread to another. In order to prevent the other threads from reading an updated value (which the API should explicitly prevent - it's thread Local after all), the inheriting thread must create copies. These drive up memory use, especially when there are many threads ("millions of virtual threads").
Once set, values must be explicitly removed (using the ThreadLocal::remove method) or they will "leak" beyond their intended use and continue to occupy memory.

To solve these problems, Java 20 incubates the Scoped Values API (for the first time). With it, the above example can be implemented as follows:

class Server {

	final static ScopedValue<Principal> PRINCIPAL = new ScopedValue<>();

	void serve(Request request, Response response) {
		var level = (request.isAdmin() ? ADMIN : GUEST);
		var principal = new Principal(level);
		ScopedValue.where(PRINCIPAL, principal)
			.run(() -> Application.handle(request, response));
	}

}

Here, too, different information is stored per thread, but there are some crucial differences to thread locals:

After a value has been bound with where, no other can be set.
Accordingly, no copies need to be created when inheriting, which significantly improves scalability.
As the name implies, a scoped value is only visible within the defined scope, i.e. within the run method - after that the bound value is automatically removed and so cannot accidentally "leak". In the example, only code that is called directly or indirectly from the lambda passed to run can see the principal in PRINCIPAL.

Migration Challenges

Java continues to evolve in many small and large steps. But after more than 25 years, this evolution also includes reversing old decisions that no longer stand the test of time, and so some technologies and APIs are being carefully removed:

Applet API
Security manager
Constructors of value-based classes
Finalization
some methods on Thread and ThreadGroup

For the background and current status of these deprecations for removal, I recommend Inside Java Newscast #41 - Future Java, Prepare Your Codebase Now!. A list of final deprecations can also be found in javadoc.

Embedded video.

In Java 20, only the removal of the methods on Thread is progressing: suspend(), resume() and stop() have had their implementation hollowed out and now throw an UnsupportedOperationException.

In addition, there are often small changes that have to be taken into account during a migration. In Java 20 this includes:

The necessity described above to allow custom object factories with the system properties jdk.jndi.ldap.object.factoriesFilter and jdk.jndi.rmi.object.factoriesFilter.
The G1 options listed above now generate warnings and should no longer be used.
When converting extremely large stylesheets to Java objects with XSLT an "Internal XSLTC error" may now occur, which can be bypassed by splitting the stylesheets.
The default timeout for idle HTTP/1.1 and HTTP/2 connections created with the java.net.http.HttpClient has been reduced from 1200 to 30 seconds.
IdentityHashMap's implementation of the methods remove(key, value) and replace(key, oldValue, newValue) incorrectly compared values (i.e. value, not key) by equality (equals) instead of identity (==) - this is now fixed.
Constructors of the URL class now check the passed strings more strictly to see whether they are valid URLs and thus more often throw a MalformedURLException. Before this change, some malformed URLs were only detected when the connection was opened and the exception was thrown then - this behavior can be restored by setting the system property jdk.net.url.delayParsing.

Summary

As boring as Java 20 may seem on the surface without major finalized features, releases like this are critical to Java's continued success. Whether security or performance, observability or tooling, existing APIs or upcoming features - Version 20 advances Java on all fronts. And, in all honesty, a little rest between groundbreaking changes is welcome - who wants another Java 9 every six months?

The Holy Grail of Java Performance - Inside Java Newscast #43

Nicolai Parlog — Thu, 02 Mar 2023 00:00:00 GMT

The goal of Project Leyden is to improve the startup time, time to peak performance, and footprint of Java programs. Project lead Mark Reinhold recently proposed to extend the Java programming model with features for selectively shifting and constraining computation with condensors. Let's look at his white paper and roadmap.

Intro

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and right now I'm at the beginning of a long trek up the mountain to search for lightning in a bottle, the holy grail of Java performance. It's not gonna be easy and you'll not always know where I'm going but trust me, if you stick with me to the end, it'll be worth it.

Ready? Then let's walk!

Phases Of Computation

Compile Time

Even a journey of a thousand miles begins with a single step, so let's start our trek with the most obvious step in any program: compilation. For JVM languages, compilation turns a bunch of source files into bytecode, right? Yes but it does more than it has to to achieve that goal. For example, it folds constants, meaning it evaluates simple expressions at compile time, so they don't need to be computed at run time. Why does it do that? You think about that while I walk a bit more...

Run Time

Got it? Great, put a pin in that.

Now let's talk about the other obvious phase: run time. It takes the compilation's results and turns it into behavior: you know, the responses of a web service, for example. One thing that stands out in Java's execution model is its inherent laziness. Uhh, talking about laziness... Late binding, lazy initialization - those are core concepts that both the runtime and us developers use to defer computation, for example with single-loaded... lazy-loaded singletons (sorry). So... put a pin in that, too.

Artifacts & Phases

So we have one phase that turns source code into bytecode and another that phase that turns bytecode into behavior. Now, the last one is a little abstract, but generally speaking we can classify source code, bytecode, and behavior as artifacts. So the two phases transform artifacts. Are there more than two? For sure!

Good Times

Since Java 9 there's a third but optional phase: link time. It transforms bytecode into a new kind of artifact, a run-time image, to achieve self-containment.

And then there's class-data sharing. Creating the archive is another optional phase but this one doesn't transform the input artifact; it augments it with additional information: the class-data archive. This improves performance, particularly launch performance.

So we have compile time, link time, archiving time, run time, STOP ... HAMMER TIME

Shifting Computation

Every phase contributes computation so our program may achieve its goals. Those goals are primarily to behave correctly but beyond that we may want it to be fast, small, quick to boot, etc. One way to achieve that is to shift computation, to move it around to a time where it better suits us.

Forward And Backward

We talked about lazy initialization earlier. It defers - shifts - computation to later, forward in time, if you will. This makes the program faster to launch than one that initializes all classes and static fields immediately on boot. (It may also avoid unnecessary computation but let's focus on shifting.)

So lazy initialization shifts computation forward - now let's get back to constant folding during compilation. As you probably figured out, by evaluating expressions at compile time instead of at run time, it improves run-time performance. In our new parlance, it shifts computation, but: It does so the other way, backward in time, and also to a different phase - that's pretty cool!

Direct And Indirect

It appears that my camera just broke or at least I can't fix it out here in the Austrian mountainside, so I'll have to record the rest of the video on my little phone camera and I'll read a little bit from the script to make up for time that I lost if that's ok with you.

So we can shift computation forward, to later, and backward, to earlier, within the same phase or across phases. There's one more distinction: We can shift direct computation, which is code that we wrote, and indirect computation, which is computation done on our behalf, like loading classes or collecting garbage. Constant folding, for example, shifts the evaluation of the expressions we wrote, which is direct computation. Lazy initialization shifts the code we wrote in the static initializer (once gain direct computation) and loading of the class itself (which is indirect computation)

With that framework in mind, let's look at the optional phases. Linking shifts indirect computation backward from run time to link time. Similarly, class-data sharing shifts indirect computation backward from run time to archive-creation time. And even the halting problem is solved during HAMMER TIME.

Generalization

As you can see, Java often shifts computation around and sometimes even introduces new optional phases when needed but so far this process has been informal and very specific to each shift and phase. And this is where we leave current Java behind and take a step into a new possible future in which we captured lightning in a bottle.

Condensing Code

So let's generalize, let's allow an arbitrary number of phases in which time-shifting transformations and related optimizations can be applied. To that end, we'd have condensers. A condenser is an optional transformation phase that takes a code artifact (like bytecode) as input and produces another artifact as output that can contain new code (like ahead-of-time compiled methods), new data (like serialized heap objects), or new metadata (like pre-loaded classes). The condenser:

performs some of the computation expressed in the input artifact, thereby shifting that computation from some later phase to the current phase
applies optimizations enabled by that shift so the new artifact is faster, smaller, or otherwise "better"
and it possibly imposes constraints, but more on that later

Condensation has three critical properties:

It is meaning preserving: The resulting artifact runs the application according to the Java Platform Specification, just as the original artifact did.
It is composable: The artifact output by one condenser can be the input to another, so performance improvements accumulate across a chain of condensers.
It is selectable: Developers choose how, what, and when to condense.

Dynamism And Constraints, Specifications And Performance

The challenge in shifting computation while preserving meaning is Java's natural dynamism: A running program can load and redefine classes and reflectively access fields and invoke methods in ways that are impossible to predict. Generally speaking, the Java Platform Specification does not allow computation to be shifted in time arbitrarily, which prevents many powerful optimizations.

And this is where the constraints that I mentioned a minute ago come in. The Java Platform Specification, in particular the Java Language Specification and the Java Virtual Machine Specification, would be revised so that a list of permitted constraints is created: From the relatively weak constraint of selecting classes that cannot be redefined to the very strict closed-world constraint and many more in between. The Java specifications would also define the concept of condensers.

If all this comes together, we get condensers, the requirement for them to preserve meaning, to be composable and selectable as well as a list of constraints they may impose. In such a future, a program's performance would be an emergent property of the condensers selected by its developers. As they stand in front of a cabinet of lightning-filled jars, they can pick and choose as their program's properties permit and performance requirements demand. After all, these properties and demands are very different across the ecosystem and hence this flexibility is needed to allow all programs to improve performance and not just those that can accept the very strict closed-world constraint.

Roadmap

The path I've just laid out to you is described in Mark Reinhold's white paper Selectively Shifting and Constraining Computation, published last October. It's the first step of Project Leyden, which has the goal to improve startup time, time to peak performance, and footprint of Java programs. The article, linked in the description of course, lays out Leyden's fundamental challenges and approach and it ends with a roadmap:

Specifications And Tools

First, the Java Platform Specification (and the TCK for that matter) must be extended with the new concepts of condensers and constraints. Various tools, like jlink, must be improved to support condensers and artifact formats, like JAR files for example, must be augmented to accommodate new code, data, and metadata.

Bad news, clearly this episode has to end at the peak, but I'm not gonna make it there today, particularly because I also have to trek back down and if there's one thing that I know about the mountains it's not to strand there during the night. So I'm gonna regroup, I'm gonna come back another day.

Condensers And Constraints

And we're back. Where were we? Ah, right.

Then it's time to get to the meat of the matter: researching and developing condensers and suitable constraints. To list a few possible examples:

selective prohibition of redefinition of classes, which would allow pre-resolution of the selected classes, field accesses, and method invocations
selective prohibition of run-time subclassing, which would allow non-speculative ahead-of-time compilation of the selected classes
and selective prohibition of reflection, which would allow dead-code elimination

Put these and more together and you get the full-blown closed-world constraint, where you can create native images, fast-to-boot and very small, within the bounds of the Java specifications. We'd truly have found the holy grail of Java performance.

Outro

And that's it for today on the Inside Java Newscast. Thank you very much for coming along on my hike, I hope you enjoyed it as much as I did. In two weeks Billy will go over all changes in Java 20 with a fine comb and two weeks after, I finally get to show you my new studio. Until then: like, subscribe, comment - you know the drill. So long...

Watch the video.

Prepare Your Code Bases For Future Java - Inside Java Newscast #41

Nicolai Parlog — Thu, 02 Feb 2023 00:00:00 GMT

What do the security manager, applet API, finalization, and primitive wrapper constructors have in common? What about CMS, Nashorn, RMI activation, and biased locking? And what does jdeprscan have to do with all of this?

Intro

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle and today we're gonna go over all Java functionality that's deprecated for removal and what you need to do to prepare your code bases.

No, no, don't leave! Don't leave. Look, look, I know it's not as thrilling as talking about fancy new features like we did in the last episode, but it needs to be done. I want all your projects to be ready to move to the next version you choose, whether that's Java 17, 20 in March, or 21 in September, and for that you need to know about these things.

To make it a bit more entertaining, I'll show you all my Displates, so you can judge me for my taste, ok? And if you make it all the way to the end, I'll tell you some personal news about this space I'm sitting in.

Deal? Then let's dive right in!

Oh, I forgot to turn on the blue and yellow lights. How German of me. Better late than never, though.

jdeprscan

Before we get into specific deprecations, we need to quickly talk about jdeprscan. That's a command line tool that scans class files or JARs for uses of deprecated API elements. Very helpful, you should definitely familiarize yourself with it if you haven't already - there's a link in the description.

# let your build tool copy all dependencies into a folder
# in that folder:
find . -exec jdeprscan {} \;
# possible additions:
#  - set `--class-path` to reduce errors
#  - add `2>/dev/null` to ignore errors \

Now, importantly, you can run jdeprscan from the latest JDK release against code compiled for much older Java versions and still get up-to-date deprecations warnings. So, for example, if your code base compiles against Java 11, you can and should run jdeprscan from JDK 19 to see deprecations as they're defined in 19. Keep this in mind whenever I talk about deprecated APIs - you can easily find static uses of them in your code base and in your dependencies with jdeprscan.

As an aside, be aware that since JDK 9, the Javadoc Deprecated page has a section that lists the APIs that are deprecated for removal.

If you find uses of deprecated APIs in your code, you obviously have to remove them - I will make sure to mention appropriate alternatives in each section. If you find them in your dependencies, see whether you can file a ticket, provide additional information, offer a bounty, or open a pull request. And make sure you're using recent versions of these dependencies, so you can easily update to a fixed one when it's released.

Applet API

Nobody's using the applet API anymore, right? So no need to spend a lot of time on this. It was deprecated by JEP 289 in Java 9 with forRemoval set to true by JEP 398 in JDK 17.

Maybe the most interesting tidbit about this technology is the reason for why it wasn't already removed. And that is its use in roughly 1500 functional tests across Swing, 2D, and AWT that happen to be written as applets without having anything to do with them. Progress on refactoring these tests has been slow and won't be done any time soon.

Security Manager

The Back Story

The security manager backstory is long and complicated. It's laid out in detail in JEP 411 and summarized in Newscast #5, so here's the overly simplified, tweet-sized version:

The security manager played its role in Java's security architecture in the past but has lost efficacy over time as new threats replace old ones. What remains impairs performance, is difficult and brittle to use, often surpassed by lower-level or out-of-process mechanisms, and hence rarely used. And while it does little to improve the ecosystem's overall security, it has a noticeable maintenance cost for the OpenJDK community, particular for those responsible for security. So it was deprecated for removal in Java 17.

State of Affairs

The OpenJDK community has been focused on removing direct dependencies of JDK code on the security manager or its APIs, for example from jstatd or J M X. As mentioned in 2022's last Newscast, they've also added callAs and current to Subject as replacement for doAs and getSubject. Overall, the people working on the security manager's removal have a good understanding of how its APIs should be degraded once support is actually removed, but there's no timeline for that yet.

JEP 411's Future Work section mentions a few use cases, such as securing access to native code, which are currently often implemented by ~~abusing~~ creatively applying the security manager. Some progress has been made, for example Panama's foreign function API offers various safeguards and improvements over JNI - read more on that specifically in the Safety section of JEP 434. And there has been some research into other uses cases, but it's too early to say which of them, if any, will get replacement APIs.

`// TODO`

To evaluate your use of the security manager:

check whether your app calls System::setSecurityManager
and look out for the system property java.security.manager - for example, a launch script might set it to the class name of a custom security manager

If neither is the case, you're not using the security manager and are good to go. If you do set the security manager, though, you need to investigate what exactly you're using it for, whether that is still timely, and what alternatives exist - carefully read JEP 411 for all of that.

Value-Based Classes

I last looked into value-based classes shortly after Java 8 came out but when I read JEP 390, which was integrated in JDK 16, for this episode, I noticed that there are a number of very interesting changes and that overall, there's a quite a lot to talk about - more than I squeeze in today. So I decided to cover it in detail in a future episode and cut this section here really short.

Basically:

Rely on deprecation warnings or use jdeprecan to discover calls to the constructors of the eight primitive wrapper classes and replace them with calls to their static factory methods. So, for example, Integer::valueOf instead of new Integer.
```
var num = new Integer(42); // 👎🏾
var num = Integer.valueOf(42); // 👍🏾
```

Avoid synchronization on value-based classes like Optional or the primitive wrapper classes. You can find them with the corresponding compiler warnings or the diagnostic VM option DiagnoseSyncOnValueBasedClasses, both introduced in JDK 16. If you set the option to 2, you get a log message every time the VM synchronizes on a value-based class instance and if you set it to 1, you get a fatal error instead.

// in `main` method in class `Sync`
synchronized (Optional.empty()) { }

$ java -XX:+UnlockDiagnosticVMOptions
	-XX:DiagnoseSyncOnValueBasedClasses=2
	Sync.java

# compiler warning
> Sync.java:6: warning: [synchronization]
>     attempt to synchronize on an instance
>     of a value-based class
>         synchronized (Optional.empty()) { }
>         ^
> 1 warning
# runtime warning
> [0,239s][info][valuebasedclasses]
>     Synchronizing on object 0x000000045302d1b8
>     of klass java.util.Optional

For the backstory and more details, read JEP 390 or subscribe for the episode I'll make on this.

Finalization

The Back Story

Finalization is Java's OG resource management mechanism and has been around since its first release.

// "root definition" of finalizers
// in java.lang.Object
@Deprecated(since="9", forRemoval=true)
protected void finalize() throws Throwable { }

// example in com.sun.jndi.dns.DnsClient
protected void finalize() {
	close();
}

Unfortunately, it has a number of undesired properties:

it's always-on
has unpredictable latency
behavior in the finalizer methods is unconstrained
neither threading nor ordering can be controlled

This leads to a difficult programming model, security vulnerabilities, unreliable execution, and sub-par performance. So no wonder it was deprecated for removal in Java 18. And this was just the short version - for the slightly longer one, watch Inside Java Newscast #15, for the full version, read JEP 421

State of Affairs

The OpenJDK community is removing finalize() methods one by one and if I counted correctly, it went from 98 in JDK 8 to 55 in JDK 19 - progress but definitely still a way to go. And while I don't have insight into how the removed ones were selected, I can tell you how I tackle such tasks and it's not by solving the hardest problems first. So my personal guess is that the actual removal is still some time in the future.

# to get these numbers, clone jdk, check out a tag, and run:
grep -r --include=*.java "void finalize()" src/ | wc -l
# results:
#     jdk8-b120: 98
#     jdk-9+181: 92
#     jdk-10+46: 94
#     jdk-11+28: 90
#     jdk-12-ga: 78
#     jdk-13-ga: 76
#     jdk-14-ga: 74
#     jdk-15-ga: 73
#     jdk-16-ga: 70
#     jdk-17-ga: 67
#     jdk-18-ga: 64
#     jdk-19-ga: 55
#     jdk-20+26: 55
# this is a slight overcount - there are a few
# `void finalize()` methods in comments

`// TODO`

At this point, you should be removing finalize() methods from your project. You can find them with jdeprscan, of course, but if you don't have access to all code running in your application, you can also run it with Java Flight Recorder enabled and look out for the FinalizerStatistics event.

# launch app with flight recorder enabled
java -XX:StartFlightRecording:filename=recording.jfr ...
# analyze recording and look for finalization events
jfr print --events FinalizerStatistics recording.jfr

The primary replacement for finalizers are try-with-resources blocks, otherwise you may have to use the cleaner API - check the aforementioned Inside Java Newscast or JEP for details.

If finalizers remain but you're wondering how your project would be impacted if they're ignored, run it with the command line option --finalization=disabled. Now, no finalizers are being executed - not yours, not your dependencies', not even the JDK's.

# run app without finalization
# (i.e. the GC won't call `finalize()`)
java --finalization=disabled ...

Compared to a run without that option, a close look at memory profiles for heap and native memory as well as statistics from BufferPoolMXBean and UnixOperatingSystemMXBean::getOpenFileDescriptorCount should reveal whether there are any issues mounting up. If they all look good, you have some assurance that your application will not be impacted by the eventual removal of finalization.

RIP

There are a few technologies that projects on Java 11 or older might still be using but are already removed:

the concurrent mark sweep garbage collector was removed in 14 - in most cases G1 is an equivalent or better replacement
the JavaScript engine Nashorn was removed in 15 but continues to exist as a stand-alone project - there's a link to their GitHub in the description
RMI activation was removed in 17 - nobody seems to be using it any more and as far as I'm aware there's no alternative technology
biased locking was deprecated for removal and deactivated in 16 and removed in 18 - you can still use it on 16 and 17 with the VM option UseBiasedLocking but unless your code executes a lot of uncontested synchronized operations, which is almost exclusive to pre Java 1.2 code, you won't see a performance benefit from turning it on

And that's it for deprecated and removed technologies - you made it! See, it wasn't that bad. Did you like the Displates - which one was your favorite?

Outro

So about those news. I've been working in this room for over 6 years now and... that was ok, it did its job well, but it's also pretty small and boring - both on camera and just to be in 10 hours a day. So I'm really looking forward to my new office/studio that I will move into over the next weeks. Expect me to show you around three episodes from now - the next episode will be done by my colleague Ana-Maria Mihalceanu and the one after that I'll take you on vacation again.

And that's it for today on the Inside Java Newscast. Do all the YouTube things and say "Hi" from me to Ana in two weeks. So long...

Watch the video.

Java's Plans for 2023 - Inside Java Newscast #40

Nicolai Parlog — Thu, 19 Jan 2023 00:00:00 GMT

A summary of what happened in 2022 and what will probably happen in 2023 for Projects Amber, Galahad & Leyden, Lilliput, Loom, Panama, and Valhalla

Intro

Happy new year, -everyone-, and welcome to -the first Inside Java Newscast- in 2023. I'm Nicolai Parlog, -Java developer advocate at Oracle- and today -we're gonna take a look ahead at-

No, stop! What's going on here?! Why am I here twice?

-Valhalla, Panama, Loom, and Amber - what they're about, where they are right now, and what their plans are for 2022 and beyond-

Oh, I get it now. I did this before! Right, last January, we looked at those four projects in quite some detail for 2022. That's good, it means I can skip the introductions and just update you for 2023. And in the time that saves, we can talk about projects Lilliput, Leyden, and Galahad.

Keep in mind that, as always when discussing anything that's not yet finalized, everything may still change, and some of what will keep the JDK developers busy this year is far from finalization. Sometimes it's just an ongoing conversation without even a specific proposal having been made. Ok? Then let's dive right in!

Project Loom

Let's start with the star of 2022: Project Loom! It released virtual threads as a preview feature and structured concurrency as an incubating API in Java 19. For Java 20 it merged scoped values, an incubating API to provide functionality that's similar to thread-local variables, but much more scalable with virtual threads. Learn all about it in Jose's excellent JEP Cafe on the matter.

The main effort for 2023 will be in finalizing these features. My personal guess is that at least for virtual threads we have a decent chance that will happen by JDK 21 - the rest, I'd put in 2024 the earliest.

Another area of work is making virtual threads less clingy to the carrier/platform/operating system threads executing them. As you know, virtual threads' scalability comes from their readiness to yield the carrier thread while waiting, so they don't hog an expensive resource when they're not using it. But in the current preview in JDKs 19 and 20, there are three limitations to that:

native frames on the stack
synchronization
file system access

All of them pin the virtual thread to the carrier thread, thus limiting scalability. As far as I understand, nothing can be done about native stack frames. The other two can be tackled, though, and we can hope to see some progress on that in 2023. For file system access, the keyword is io_uring - Linux' asynchronous I/O interface. When Java adopts that, virtual threads can yield while waiting for file I/O.

Projects Galahad and Leyden

As announced at JavaOne, Oracle plans to contribute the GraalVM just-in-time compiler and Native Image to OpenJDK.

For the integration of the just-in-time compiler as an alternative to the existing JIT compiler of the HotSpot VM, the creation of a new Project Galahad was proposed by Douglas Simon in December 2022. The first goal is to move development of Graal's JIT into the OpenJDK community. Once it matches or outperforms HotSpot's JIT on a selection of important metrics like memory footprint, warmup time, and compilation speed, it can be integrated into the JDK main-line repository, so it becomes an alternative to HotSpot's JIT.

Note that HotSpot's JIT is written in C++ whereas Graal's is written in Java and comes as bytecode. Just-in-time compiling itself to optimized machine code is possible but interferes with application performance, so the next step for Galahad would be to bring in the necessary ahead-of-time compilation technology to make this new JIT compiler available instantly on JVM start and avoid any interference. And here, the line to Project Leyden becomes a bit blurry.

Leyden has the goal to address the long-term pain points of Java's slow startup time, slow time to peak performance, and large footprint. It picked up a bit of steam last year and in October project lead Mark Reinhold published a very interesting white paper. I'll go into that and Leyden's approach in detail in a future episode - subscribe if you don't want to miss that. For now, suffice it to say that while it plans to achieve its ultimate goal with static images like the ones Graal's AOT compiler can create, this will likely be the last step on a path from unconstrained, dynamic Java to a full closed-world constraint that allows for these static images.

So both of these projects are glancing at AOT in the distance and will tackle it from different angles in due time. But they're still pretty young, so don't expect anything major in 2023 or probably even 2024. But if you're interested in these topics, make sure to follow their mailing lists! Although Galahad doesn't have one yet - Leyden's is linked below.

Project Panama

Project Panama's vector API is extremely stable at this point - so much so that there weren't any changes in JDK 20, so not even a JDK Enhancement Proposal was filed for it. Still, it will stay incubating until Project Valhalla starts delivering features - more on that in a few minutes - because those allow significant improvements to the API.

Panama's second prong are its foreign memory and function APIs. They went from incubating to preview in JDK 19 and there have been a few small changes in JDK 20, namely the removal of the class MemoryAddress in favor of MemorySegment and the split of MemorySession into Arena and SegmentScope.

For future work, let me quote from a mail that project lead Maurizio Cimadamore sent to the Panama mailing list:

[I]t's fair to say that more time (and feedback) is required to understand if lifetime management in the FFM API has reached its lowest energy state (which might, in turn, affect our chances to finalize the FFM API in 21). This is perhaps not surprising: one of the main challenges of the FFM API is that to bring timely and safe deallocation [to] a programming language that is built around the idea of implicit deallocation, managed by a garbage collector. As such, we should make sure we get this absolutely right.

And on jextract he wrote:

[P]ossible areas of improvement [...] include adding first class support for capturing errno [...], improving the mapping for C structs, and investigate ways to reduce the static footprint of the jextract generated code

There are also additions to the linker API on the horizon, like possibly allowing Java code to pass heap segments directly to native calls. They may be worked on in 2023 but won't be delivered before the FFM API is finalized.

Project Lilliput

I gave an intro to Project Lilliput before - check it out here. The gist is that it tries to reduce the size of the object header in Hotspot from 128 or 96 bits to 32 bits. This would free up 10-20% of your heap! Not bad.

In May of 2022, Lilliput achieved its first milestone and reduced header size to 64 bits. And in December it published a fork of jdk17u with those changes. I don't think they released an early-access build but building your own JDK isn't even that complicated - there's a link to the guide in the description.

For 2023, project lead Roman Kennke sees a good chance to achieve the 32 bit goal. That would be very, very cool! If you can't wait that long, check out JOL - or J. O. L.? - Java Object Layout, a toolbox to analyze object layouts in JVMs. Aleksey Shipilëv recently extended it to simulate Lilliput's current state and its goal. You can feed JOL a heapdump and get an estimate of Lilliput's effect on your project.

Project Valhalla

Hm, Project Valhalla... what can I say here. It seems every time we check how far it's along, it's still as far from the finish line as the last time we checked. It seems like nothing much is happening.

That's not the case, though. In 2022, its proposals were consolidated and fleshed out and in November it published an early access build based on JDK 20 that presents a huge portion of its features. This improved the understanding of the current proposal and, as it turns out, lead to the team not being very satisfied with primitive types as they are proposed by JEP 401. They're working through alternative approaches in the language to surface the same functionality, which means changes to that JEP are probably coming. Then we'll see where that leaves us for getting things delivered.

I know this can be frustrating. Valhalla promises a revolution to the type system, a much more uniform and expressive language, as well as a considerable performance boost and all that while keeping billions of lines of existing Java code running as before. You know, said like that, I kinda understand why it's taking so long.

Project Amber

As if to make up for Valhalla, the other project Brian Goetz leads - Project Amber - can't stop producing ideas and features! In 2022, it first previewed record patterns and progressed on pattern matching for switch and personally I see a good chance for both of them to be finalized in 2023. As for the many ideas

(a) they are all very young with often indeterminate futures and (b) I don't have the time to explain all of them anyway,

so I will just quickly enumerate them from most concrete to most pie in the sky - by my personal guesses:

string templates would make embedding expressions like variables or method calls in strings both more comfortable and more secure

String property = "last_name";
String value = "Doe";

Statement query = SQL."""
	SELECT * FROM Person p
	WHERE p.\{property} = '\{value}'
	""";

the single underscore may become the unnamed pattern or variable, marking variables that you need to assign for syntactic reasons but don't intend to use

Optional<User> user = findUser();
user.ifPresent(_ -> System.out.println("Found!"));

record Address(String street, String city) { }
Object something = // ...
if (something instanceof Address(_, var city)) {
	// ...
}

primitive types may become legal in patterns

int i = ...;
switch (i) {
	case byte b -> /* use `b` */;
	case float f -> /* use `f` */;
	default -> /* ... */;
}

it may become possible to execute statements before super() calls in constructors

public SuperUser(
		String firstName, String lastName,
		String street, String city,
		Permissions permissions) {
	Name name = createName(firstName, lastName);
	Address address = createAddress(street, city);
	super(name, address);

	this.permissions = permissions;
}

imperative destructuring is when you apply a destructuring pattern like record patterns on variable declaration and it's coming

record Pair<L, R>(L left, R right) { }
public Pair<String, String> find2Strings() {
	/*...*/
}

// take return value apart into two
// newly-declared variables
Pair(var s1, var s2) = find2Strings();

launching a Java program may become considerably simpler - also known as paving the on-ramp

void main() {
	println("Hello, World!");
}

we haven't heard about "withers" in a while but they're still on the road map and with record patterns out in preview I hope to hear more about this soon

record User(String name, String address) { }
User user = getMeSomeUser();

// made up syntax
User newUser = user with {
	name = "John Doe";
}

At this point, I'm such an Amber fanboy, I want a jersey and one of those big foam hands to cheer it along!

Outro

And that's it for today on the Inside Java Newscast. If you enjoyed this episode, don't waste your time liking or subscribing - instead head over to inside.java right now. It aggregates all the important news in a very timely manner and little of what I link in the description wasn't linked there before. Take a look around and subscribe to the RSS feed.

I'll see you again in two weeks! So long...

Watch the video.

24 Java Features You Missed In 2022 - Inside Java Newscast #39

Nicolai Parlog — Thu, 15 Dec 2022 00:00:00 GMT

JDK 18 and JDK 19 preview a number of big ticket features but they also come with a lot of smaller improvements. Here are 24 less-known features that were added to Java in 2022. Among them additions to Future and ForkJoinPool, to HashSet and HashMap, Security and GC improvements, Custom Localized Date-Time Formats and an Internet Address Resolution SPI, and much more.

Intro

Ho, ho, ho and welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nikolaus Parlog, Java developer advocate at Oracle and bringer of presents, and today we're gonna unbox 24 Java features you missed in 2022. From language features to API additions, from tooling to performance - my advent calendar is filled to the brim.

Wait, it's not Nikolaus who brings the advent calendar, right? And doesn't this look like Santa Claus' cap? Also, this fake fur jacket looks way kinkier than anything either of the two would ever wear. Ugh, nevermind, I can't do the voice the entire episode anyway. I'll just look weird, then.

So are you ready for 24 features, small and large, safe and fast? Then let's dive right in!

Structured Concurrency Debugging

JDK 19 famously previews Project Loom's virtual threads and people have also taken note of the structured concurrency API it is incubating. One aspect of that approach to concurrency that can hardly be overstated is the relationship it introduces between threads. If one thread launches a few subtasks each in their own thread and then waits for them to complete there's a clear parent-child relationship between those threads. And it's expressed at run time, so it's visible in thread dumps and during debugging.

In fact, just the other day I noticed that IntelliJ now allows navigation of that hierarchy - so cool! This will be a game changer for debugging when you can go from any random subtask that you paused in all the way up to the very thread that handles the entire use case or request.

Chaotic Concurrency 😋

Speaking about structured concurrency: It relies on the class Future but you'll usually only ask instances of them for exceptions or results when they already completed. To make that easier to determine and request, Future got three new methods:

exceptionNow() to immediately return the exception thrown by the task
resultNow() to immediately return the task's result
state() to check whether the Future is in an appropriate state to request exception or result - because if it's not, the other two methods throw IllegalStateExceptions

More has changed for pre-existing concurrency APIs in JDK 19:

ForkJoinTask got two new variants of joining quietly, namely quietlyJoin with timeout and quietlyJoinUninterruptibly, also with timeout.
On ForkJoinPool, you can now submit tasks lazily that you don't need to execute if contention is high with lazySubmit; and with setParallelism you can set the pool's target parallelism after creation.

Hash, Set, and Map 🎾

When you know exactly how many elements your HashSet has to contain, how do you create one of correct size, so that no resizing is necessary? Pass that number as initialCapacity to the constructor? Nope, because there's a load factor in play, usually 75%. Once the set contains that many elements relative to capacity, it will resize.

// a capacity of 64 with the default load
// factor of 0.75 leads to a resize after
// 49 elements were added
var capacity64 = new HashSet<String>(64);

To avoid the resize, you can compute capacity from expected element count via the load factor... or you can use the static factory method newHashSet that was added in JDK 19 and pass in the number of elements - it will do the math for you. Same for HashMap, by the way, except it's called newHashMap, obviously.

// this set has sufficient capacity to accept 64
// elements before resizing
var elements64 = HashSet.<String> newHashSet(64);

GitHub Action

The GitHub action oracle-actions/setup-java allows you to easily set up various OpenJDK builds from jdk.java.net:

general availability builds, currently JDK 19
early-access builds of mainline JDK, for example JDK 20 and soon JDK 21, and
early-access builds of projects like Loom and Panama

It also allows you to set up Oracle JDK builds from oracle.com/java - the NTFC license gives you a lot of leeway to use it for free.

Compressing and Expanding

Say you have a vector of RGB values and want to create a new vector with just the reds at the beginning and everything else set to zero. How do you do that? A rearrange with a shuffle and a mask would do the trick, but it's tedious and non-obvious. JDK 19 added a more succinct operation to the vector API to accomplish this: compress. Just pass in a mask of the lanes you want to select and they'll be placed in a contiguous section at the beginning of the result vector, with everything else set to 0.

int[] colors = { 255, 79, 198, 87, 160, 255, 179, 228 }
boolean[] selectRed = { true, false, false, true, false, false, true, false };

// this example only works if the species has length <= 8
var rgbVector = IntVector.fromArray(SPECIES, colors, 0);
var redMask = VectorMask.fromArray(SPECIES, selectRed, 0);
var reds = rgbVector.compress(redMask);

To go the other way, use expand: Starting from index 0, lanes are parceled out into each result lane where the mask is true. Spiritually speaking, compress and expand are inverse to one another but not quite because both lose information, namely the non-selected lanes. But if you compress and then expand with the same mask, you get the input vector back with all lanes that the mask didn't select set to zero. Beautiful.

Now, here's a cool thing! Take an int - 32 bits - and imagine it as a vector with 32 lanes. Compressing and expanding applies here, too, right? And the mask would be 32 booleans/bits, so another int. Hence Integer got new static methods compress and expand that accept the "input vector" and the "vector mask" as int arguments and return an int. Same for Long but with long. By the way, at least on x86 processors this is implemented as an intrinsic leveraging the PEXT instruction, which makes it lightning fast.

Suppressing Javadoc Linting

You write Javadoc, right? And you use DocLint to check for potential problems, right? And you fix all of those immediately, right?

If you answered yes, yes, no, respectively, then I got good news for you: You can now suppress DocLint warnings with the usual @SuppressWarnings annotation.

// suppress all doclint warnings
@SuppressWarnings("doclint")
// suppress warnings for syntactic issues
@SuppressWarnings("doclint:syntax")

String Deduplication

Since 2017, the G1 garbage collector deduplicates strings, meaning it detects string instances that are equal and retains only a single copy of the backing character array. Measurements done on a large number of Java applications big and small have shown that on average 25% of heap data are String objects and about 13.5% are duplicated - removing their backing character arrays reduces memory footprint by roughly 10%. Since JDK 17, Shenandoah and since JDK 18, ZGC, Serial GC, and Parallel GC also support string dupdidup de dup dep dupli deduplication. Damn it!

// `s1` and `s2` are equal if:
boolean equal = s1.equals(s2);

G1 Region Size

Ugh, if I can't even get "deduplication" out, I probably need a break, so let's have one. By the way, I have a question. On another Newscast, recently, I mentioned that "this is a different Newscast because you actually have to sit down and watch the screen" whereas the other ones, like this one, you usually don't. You might be, you know, preparing lunch or putting together the laundry or whatever and can still listen to me. And I asked myself, what are you actually doing? Like, how do you usually watch these episodes? I'm really curious to find out, so please leave a comment - I really wanna know.

Also, let's change this around a bit. Wait, what? There and there. Ah, man, see - there we go!

Ik, coming back to G1, the maximum allowed heap region size of 32MB can cause inner and outer fragmentation issues with larges objects on large heaps. On very large heaps, it leads to increased internal region management overhead and decreased performance due to larger local allocation buffers. Since JDK 18, it's possible to manually increase the heap region size beyond 32MB to up to 512MB with the command line option -XX:G1HeapRegionSize.

$ java -Xlog:gc* -XX:G1HeapRegionSize=512M
# [...]
# [0.002s][info][gc,init] Heap Region Size: 512M
# [0.002s][info][gc,init] Heap Min Capacity: 512M
# [0.002s][info][gc,init] Heap Initial Capacity: 1G
# [0.002s][info][gc,init] Heap Max Capacity: 16G
# [...]

Good right, that was good? Pause worked, let's keep going.

Security Performance

JDK 19 ships with several performance improvements for security-related code:

The JDK's SHA3 message digest algorithm performance has been increased up to 2x.
The local certificate objects used to resume a TLS session from stateless session tickets are now cached and reused, which reduces memory consumption.
SSLAlgorithmConstraints are no longer evaluated twice, which increases TLS handshake performance.
And another speedup in the same area comes from caching the results of constraints checks.

Got all that? Me neither, but good to know that Java gets faster.

Custom Localized Date-Time Formats

To turn a date-time into a string, you need a DateTimeFormatter. Creating custom formatters is easy with the static factors method ofPattern. And creating localized formatters is easy, too, as long as you stick with the four predefined FormatStyles SHORT, MEDIUM, LONG, and FULL. But what about custom localized formatters? JDK 19 is there for you!

It adds the static factory method DateTimeFormatter.ofLocalizedPattern that accepts Unicode "skeletons", which only define what fields you want to include but leave the formatting and order for the localization to determine. The DateTimeFormatterBuilder class was also extended with the methods getLocalizedDateTimePattern and appendLocalized.

var now = ZonedDateTime.now();
Stream.of(
		Locale.of("en", "US"),
		Locale.of("ro", "RO"),
		Locale.of("vi", "VN")
).forEach(locale -> {
	Locale.setDefault(locale);

	var custom = DateTimeFormatter.ofPattern("y-MM-dd");
	var local = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT);
	// it's now possible to create custom
	// localized formatters for specific patterns
	var customLocal = DateTimeFormatter.ofLocalizedPattern("yMM");

	System.out.printf(
		"%s  | %s | %s | %s %n",
		locale, now.format(custom),
		now.format(local), now.format(customLocal));
});

Output:

locale |   custom   |  local     |   both
en_US  | 2022-12-14 | 12/14/22   | 12/2022
ro_RO  | 2022-12-14 | 14.12.2022 | 12.2022
vi_VN  | 2022-12-14 | 14/12/2022 | tháng 12, 2022

Javadoc Search

Since JDK 19, Javadoc's search box can handle multiple search terms. And to make it easier to navigate results, there's now a page for those.

This seemingly small change has a pretty cool consequence - we can now sidestep the entire Java version search fiasco and create a custom browser search for each JDK version we want. If you don't know how to do that, I link to explanations for Firefox and Chrome in the description.

jarsigner Provider Path

The new option -providerPath has been added to jarsigner. It allows you to specify the class path of an alternate keystore implementation and can be used in conjunction with the -providerClass option.

$ jarsigner \
	-keystore keystore \
	-storetype MYKS \
	-providerPath mods/test.myks \
	-providerClass org.test.MyProvider \
	signed.jar mykey
> Enter keystore password:
> jar signed.

Address Resolution SPI

The class java.net.InetAddress is in charge of resolving host names and addresses, for which it relies on the operating system's native resolver, which is typically configured to use a combination of a local hosts file and the Domain Name System. That has a few downsides: For one, it clashes with virtual threads because for the time being file-system access pins them to platform threads. And then, it makes it harder to impossible to support emerging network protocols, customization, or testing.

So since JDK 18, you can plug in your own resolver for host names and addresses by implementing the types InetAddressResolver and Idres... Eh. Since the announcement that Idris Elba is gonna be in Cyberpunk 2077... mouths explosion Anyway. You have to implement InetAddressResolver and InetAddressResolverProvider and register the latter as a service.

public class ForwardingInetAddressResolverProvider
	extends InetAddressResolverProvider {

	@Override
	public InetAddressResolver get(Configuration configuration) {
		return new ForwardingInetAddressResolver(
			configuration.builtinResolver());
	}

	@Override
	public String name() {
		return "Forwarding";
	}

}

public class ForwardingInetAddressResolver
	implements InetAddressResolver {

	private InetAddressResolver builtinResolver;

	public ForwardingInetAddressResolver(
			InetAddressResolver builtinResolver) {
		this.builtinResolver = builtinResolver;
	}

	@Override
	public Stream<InetAddress> lookupByName(
			String host, LookupPolicy lookupPolicy)
			throws UnknownHostException {
		System.out.printf("Looking up '%s'.%n", host);
		return builtinResolver.lookupByName(host, lookupPolicy);
	}

	@Override
	public String lookupByAddress(byte[] addr)
			throws UnknownHostException {
		System.out.printf("Looking up '%s'.%n", Arrays.toString(addr));
		return builtinResolver.lookupByAddress(addr);
	}

}

Metal Rendering

On macOS, an alternative implementation of the Java 2D rendering pipeline was developed that uses the Apple Metal API instead of the deprecated OpenGL API. It's fully functional and generally performs better, sometimes by a lot, than the OpenGL implementation. That happened for JDK 17, but in 19, the new pipeline became the default.

Ah, this thing is itchy. Eh, let's take it off. Oh crap, we can't have that. Better.

JAAS without Security Manager

Part of the Java Authentication and Authorization Service, JAAS how nobody calls it, depends on the SecurityManger, which, as you probably know, is deprecated for removal. So in JDK 18, two new methods were added to the JAAS class Subject:

callAs is a replacement for doAs and
current is a replacement for getSubject

The new methods are similar to but a bit simpler than the old ones, which are deprecated for removed.

Named Record Patterns

I'm sure you've heard about record patterns, which preview in JDK 19, and that you can use them to deconstruct a record into its constituent components. But did you notice that you can also assign the record itself to a variable? This is called a named pattern and is really useful when you need to reference the record itself, too. And it becomes outright magical when you nest record patterns because then you can capture an inner component while destructuring it further.

public static void main(String[] args) {
	Object obj = RandomGenerator.getDefault().nextBoolean()
			? new Point(0, 0)
			: new ColoredPoint(new Point(1, 1), "Green");
	if (obj instanceof Point(int x, int y) point)
		System.out.printf("Point %s with x: %s / y: %s%n", point, x, y);
	else if (obj instanceof ColoredPoint(Point(var x, var y) point, var color))
		System.out.printf("%s point %s with x: %s / y: %s%n", color, point, x, y);
}

record ColoredPoint(Point point, String color) { }

record Point(int x, int y) { }

Simple Web Server

Need a web server to launch a static site, maybe for demos or tests? Since Java 18, the JDK ships with a web server, which you can launch with the binary jwebserver. You can do a few fancier things with it - there's link to an article in the description - but overall it's intentionally simple and explicitly not meant to be used in production.

Outro

And that's all the 24 Java features Santa Nikolaus or whoever brought in his cap - that's how this works, right? But I found a few more and put them into a pinned comment. Check it out if you're interested and maybe spring a like or a subscribe while you're at it.

That's it for 2022 on the Inside Java Newscast. What a year! Thank you very much for watching and I wish you a relaxing few days with friends and family before the craziness returns in January. So long...

Watch the video.

From Idea to IDE - How Java Features Are Considered, Designed, And Shipped

Nicolai Parlog — Sun, 13 Nov 2022 00:00:00 GMT

How a community of Java enthusiasts drives innovation for 15 years, turning ideas into designs into code into features you can use in your IDE

OpenJDK is one of the world's most influential open source communities. It drives the reference implementation of Java SE and the Java Virtual Machine, a programming language and runtime environment used daily by millions of software developers. More than that, the community drives its innovation - 15 years and counting of new language features, core library additions, performance improvements, runtime enhancements, and new tooling.

But how does it all work? How does a community of Java enthusiasts, often financed by some of the biggest tech companies yet working with self-determination, turn ideas into designs into code into features you can use in your IDE? Well, let me explain (in this talk).

GraalVM In OpenJDK And More JavaOne Announcements - Inside Java Newscast #36

Nicolai Parlog — Thu, 03 Nov 2022 00:00:00 GMT

Oracle will contribute GraalVM's just-in-time compiler and native image technology to OpenJDK. It will also create EA and GA builds for JavaFX 20+ and is hard at work at creating generational ZGC to vastly improve ZGC's already impressive performance. And then there's the Java SE Subscription Enterprise Performance Pack, a drop-in replacement for JDK 8 with JDK 17 performance.

Intro

Speaking of JavaOne, I had a blast! I'm gonna talk a bit about that later. But first the technical stuff.

Are you ready? Then let's dive right in!

JavaFX 20 EA Builds

One thing I found astounding about JavaFX in recent years is that, even though it's a full-blown, rich UI toolkit, it's also just a library that can (and must) be downloaded on its own. It's developed under the OpenJDK project OpenJFX, with strong contributions by Gluon and Oracle.

That's all yesterday's news, though. Today's news is that Oracle will begin producing JavaFX builds on the latest versions of Java. And you can already download JavaFX 20 early access builds from jdk.java.net - just next to the Java 20 EA builds. And when Java 20 turns GA, so will JavaFX 20.

By the way, if you're looking for a runtime that includes JavaFX, you can download both the JDK and JavaFX and then use jlink to create just that.

OpenJFX co-lead Kevin Rushforth from Oracle also confirmed that JavaFX will continue to see development and with a particular eye on making it easier for beginners to get started. We think JavaFX is an important tool for education and learning to build things with Java, a topic that will become more important in Java's third decade.

GraalVM Comes To OpenJDK

GraalVM has been developed by Oracle but outside of OpenJDK and that has caused differences in release schedules, features, and development processes. To make sure those obstacles don't hinder adoption and participation in the development of GraalVM technologies, Oracle will contribute the GraalVM just-in-time compiler and Native Image to OpenJDK.

This way they will be developed with the same methods, processes, and schedules as Java. That means two feature releases per year with support for the respective Java SE version as well as four quarterly critical patch updates per year. Oracle will also offer long-term support for every fourth feature release.

But we're not there yet! The plan is to create a new OpenJDK project that investigates the contribution of these technologies. Native Image specifically will be evolved to track Project Leyden as it paves a path to fully-static images in a future release of Java SE. When suitable portions of GraalVM are ready to be proposed for inclusion into the main-line JDK source code, that will happen through the usual JDK Enhancement Proposal process. In the mean time, we might see early access releases on jdk.java.net just like for other important projects like Loom and Valhalla.

A few more insights on this are in the official announcement, link in the description, but many details will have to be worked out over the coming months and years. If you don't want to miss anything, make sure you're subscribed to this channel and regularly check out our OpenJDK news aggregator at inside.java.

Java SE Subscription Enterprise Performance Pack

Java SE Subscription Enterprise Performance Pack - a name that rolls off the tongue like a molten plastic spoon. I'll just call it EPP for short, but don't you dare repeat that or I get into trouble! So what is EPP?

In the seven years from Java 8 to 17 there have been a lot of memory management and performance improvements: From garbage collection algorithms to compact strings, from lock contention to enhanced observability, there were dozens of optimizations. Now, I've been telling everybody who listens and a lot who didn't to switch to Java 17 or later to get all that good stuff. But if you absolutely don't want to update, if Java 8 is the hill you want your project to die on, then take a look into EPP.

It's a drop in replacement for JDK 8 that is available, at no additional cost, to all Java SE Subscription customers and OCI users. It brings JDK 17 performance to JDK 8 server loads on 64-bit Linux on Intel and ARM. For heavily loaded apps we've seen memory and performance improvements of about 40% and even apps not running near capacity may see an up to 5% improvement.

To opt-in today, check the link in the description.

Generational ZGC

ZGC is a garbage collector that, in the trade-off between footprint and pause-times, went all in on minimizing pause-times. It does an amazing job at that, but one trick it doesn't use so far is to rely on the weak generational hypothesis. The weak generational hypothesis states that most objects only live a very short time and GCs can optimize for that pattern for better performance and lower foot-print.

The OpenJDK community is working hard on allowing ZGC to do just that, they call it generational ZGC, and preliminary benchmarks are looking fantastic. In a Cassandra 4 benchmark straight from the lab, generational ZGC required just 25% of the memory to fulfill the same service requirements. That's huge! Or rather, tiny.

As an aside, Parallel GC and G1 of course also see continuous improvements and particularly the latter has seen a steep drop in native memory overhead from Java 8 to 19.

JavaOne

So let's talk a bit about JavaOne. As I said, I had a blast! I could swoon over great talks and labs, over meeting community rock stars and OpenJDK luminaries, over group lunches, community get-togethers, or the parties. Instead I want to tell you about... you!

Because the best thing was that I got to meet so many you, you amazing humans! Talking to you about Java, the Newscast, or a project of yours is so damn cool and I'm really happy for every single conversation. So wherever you see me, maybe at J-Fall later today, don't be shy, I love to talk to and hear from you.

Regarding catching up on JavaOne: For now only the three keynotes are online. I'm not sure whether more talks will be published, but if so, they'll all end up on this channel and specifically in the playlist that's linked below.

And if you want to do me a favor, give the community keynote a view. It's the least interesting keynote from a technological perspective but I got to organize it with my colleagues Ana and Heather and am pretty proud of what we put together. It talks about how the community and every single member of it like you, is the future of Java and wants to inspire you to contribute more. How? That's what it's about! Go check it out.

Outro

And that's it for today on the Inside Java Newscast. Since you made it all the way to the end, do me a favor and hit that like button. Also, subscribe, click the bell, and don't forget to share this video with your friends and enemies. Newscasts will be coming every two weeks, but I'm gonna take a break to cure my hangover and meet you again mid December - Billy and Jose will be there for you until then. So long...

Watch the video.

The Simplest Hello World - Inside Java Newscast #35

Nicolai Parlog — Thu, 06 Oct 2022 00:00:00 GMT

Visibility, classes, methods, instance and static members, parameters - a newcomer to programming needs to learn all of these concepts to truly understand a simple hello-world program in Java. Time to make that simpler and cut down on what needs to be known up front.

Intro

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna look at how the smallest possible Java program may soon turn from "public class Hello public static void main String bracket bracket args" to, wait for it, "void main".

Right?! That we get to see the day! But there's a lot more to this than meets the eye and before getting to the technical aspects we need to explore why and for whom this set of changes is being proposed. Because we'll also see that it's not actually just one change, but a set of them packaged together. Ready? Then let's dive right in!

Target Audience

If you're watching this channel, chances are high that you have at least a few years of experience coding with Java and feel very at-home with the language. Then this change is not proposed for you! Yes, us experienced Java devs will have it easier to write scripts in Java, something I find really refreshing, but that's just a bonus. We're not the target audience!

Then who is? Students! Newcomers to Java or even to programming. People who can really benefit from a quick win and see their first piece of code working immediately without wading through a lengthy tirade about visibility, classes, instances, and so forth or, worse, "just install this IDE", which might very well be the most complex app they've ever launched. For them, every concept that they don't have to learn upfront is a win. So let's talk about those concepts.

Concept Overload

Looking at a small Java program, here's what's staring back at you:

visibility
classes
methods and their
- visibility
- static-ness
- return type
- a special name
- and parameters
finally the convoluted System.out.println

That's a lot to grok, particularly if it's the first time you're writing code, ever. And yes, you can tell a beginner to "just ignore all that", but that kills the very curiosity that drives learning.

A few days ago, Brian Goetz, Java Language Architect at Oracle, and his team published a design document that he has also sent to the Project Amber mailing list. Instead of expecting beginners to jump on the highway of Java concepts, it proposes to build an on-ramp. Let's change the Java launch protocol in a way that

(a) users can write a Java program on a small set of concepts (not necessarily the smallest one, though)
(b) new concepts can be learned in the order in which they appear useful to the beginner
(c) there's no unlearning, no subtle "this works differently now", as they drive up the on-ramp

So let's see how to make the launch protocol more tolerant, so it can support these goals.

A More Tolerant Launch Protocol

Let's tackle this inside out, which also happens to sort this in order of increasing excitement.

First and least, System.out.println() is stupid long and let's not even talk about what you need to do to create a simple readln() equivalent for System.in. So the proposal is to create two static methods println() and readln() that will then be auto-imported.

Next up is main itself. Skipping some details, the idea is to make most of the magic incantations optional: args, static, public - some or all can be absent and the launcher will still find the main method in a class in the unnamed package, which is where simple scripts usually start out. Like this entire proposal, this will of course be structured so that old programs behave like they always did - it's all 1000% backwards compatible.

Finally, and most extravagant, is the proposal to drop the requirement for main and other methods in the same file to be wrapped into a class. Yes, you got that right, free floating methods! But just in the freshly minted concept of the unnamed class, so nothing to put into your IRL project.

There are two cool things at play here: One is that void main is so much simpler than the full sing-song - learn about methods as containers for statements and off you go. The other is that there's a natural progression to a regular program!

Need arguments? Great time to learn how they work and add args.
Need to simplify code? Learn how to create more methods, how to pass arguments and results.
Need shared state? Add fields! (Yes, the unnamed class can have fields.)
Need more functionality? Explore JDK APIs beyond println and readln and how to import and use them.
Need a better structure? Take all you already learned, wrap a class around it, and put it into a separate source file.
Even more structure? Now's the time for packages and visibility.

So not only many small steps, most don't even require a specific order! The beginner can start simple and then add concepts as they're needed to accomplish a goal. So cool!

What Is This?

If this isn't your first Inside Java rodeo you might have noticed the curious absence of the words "JDK Enhancement Proposal". That's because this isn't one yet. The idea of an on-ramp has been stewing in the whiteboard phase for a while and has just now graduated into a Project Amber design document. That means it's still very early and lots of things can evolve or be dropped before we see any actual change.

So now is a good time to chime in! Not from a code golf, "how can we get rid of every character"-perspective, but with the intent to provide future developers the best possible way to learn programming with Java. There are links to the document, to Brian's email, and to the Project Amber mailing list in the description.

Outro

And that's it for today on the Inside Java Newscast. Since you made it all the way to the end, you probably liked the video - why not let YouTube know? Also, subscribe, click the bell, and don't forget to share this video with your friends and enemies. In two weeks is JavaOne and I'll be pretty busy with that, so I'll see you again in four. So long...

Watch the video.

The SolutionFactory To Java's Problems

Nicolai Parlog — Fri, 30 Sep 2022 00:00:00 GMT

Project Amber steadily and carefully chips away at Java's persistent pain points. This talk discusses released, previewing, and upcoming features achieve that and make Java more expressive, more succinct, and more readable.

Java has issues! Verbose, cumbersome, no expressiveness, no fun. (Or so the kids say.)

Jokes and the craving for syntax sugar aside, Java does have some persistent pain points and Project Amber was set up to tackle them. Not as a single solution to a narrow problem, but as a solution factory that's steadily and carefully chipping away at them:

text blocks and interpolation to untie the knots in dealing with strings
pattern matching, records, and sealed types against the clunkiness of operating on data
var, records, and destructuring to reduce redundancy in variable and type declarations
a relaxed launch protocol to pave the on-ramp for Java beginners

We'll look at these features individually and how they play together to make Java more expressive, more succinct, and more readable. After this talk, you'll know how Project Amber drove and drives the evolution of the language.

Data-Oriented Programming - Version 1.1

Nicolai Parlog — Tue, 27 Sep 2022 00:00:00 GMT

Data-oriented programming models data as data: records for entities and sealed types for alternatives. Combined with pattern matching we can define operations on the data without overloading it with functionality.

In data-oriented programming (DOP), we model data as data and polymorphic behavior with pattern matching. This talk will introduce the concept of DOP and its four principles:

model data immutably and transparently
model the data, the whole data, and nothing but the data
make illegal states unrepresentable
separate operations from data

We'll also explore how to use pattern matching as a safe, powerful, and maintainable mechanism for ad-hoc polymorphism on such data that lets us define operations without overloading the types with functionality. The talk ends with a juxtaposition to OOP, so you not only learn how to employ DOP but also when (not).

Loom in the Java Ecosystem - Inside Java Newscast #34

Nicolai Parlog — Tue, 27 Sep 2022 00:00:00 GMT

Among other things, Java 19 ships with virtual threads, structured concurrency APIs, sealed types, and pattern matching in switch - all of them as previews, but still very cool! I'm using these features here to create a GitHub crawler.

This episode was not scripted and so there's no written version of what I said. Another one you gotta watch. 😉

Here are links to the chapters and all other sources (basically the video description):

First Take
Intro
Project Loom Recap
Tooling
Web Servers
- Jetty
- Netty
- Tomcat
- Piranha Cloud
Frameworks
Outro

Watch the video.

Java 19 in Action - Inside Java Newscast #33

Nicolai Parlog — Thu, 08 Sep 2022 00:00:00 GMT

This episode was not scripted and so there's no written version of what I said. Looks like you gotta watch this one. 😉

Here are links to the chapters and all other sources (basically the video description):

Meet The Crawler And Warm Up With Records
- ⇝ IJN #32 on string templates
- ⇝ JEP Cafe #11 on virtual threads
Virtual Threads
- Blocking HTTP Client?
- "Interception by Project Amber!"
  - ⇝ JEP Cafe #13 on structured concurrency
Structured Concurrency
Data-Oriented Programming

The repository is linked in the sidebar.

Watch the video.

String Templates, JavaFX 19, Deserialization, and more at JavaOne - Inside Java Newscast #32

Nicolai Parlog — Tue, 23 Aug 2022 00:00:00 GMT

String templates make it easy and safe to embed variables and expressions in strings; JavaFX 19 comes with many improvements, chief among them derived observables; and the deserialization filter can keep apps safe from certain attacks. More on all of this at JavaOne!

Intro

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today I have another JavaOne-inspired mix of topics for you, namely string templates, the deserialization filter, and JavaFX 19.

Like last episode, where I talked about sequenced collections and pure functions, all links are in the description, even some that don't exist yet. Other than that, be sure to check out oracle.com/javaone and I'll hopefully see you in Las Vegas, October 17th to 20th.

Ready?

Nope, not yet. Nicolai in the editing room here and .. No I'm not gonna turn the camera on ... Because I'm not wearing pants ... I'm working from home - who wears pants for that? Anyway, if you get a ticket for JavaOne, use code INSIDEJAVA (all caps, no spaces) for a hefty 400 $ discount. Now we're ready.

Then let's dive right in!

String Templates

Let's start with something very cool that Java will hopefully get next year and that we briefly talked about in the recent OpenJDK Q&A: string templates. When you have variables and want to put them into a string, Java offers various ways to do that, for example concatenation with a + or calling String::format or Message::format.

String property = "last_name";
String name = "Doe";

// needed:
//     SELECT * FROM Person p
//     WHERE p.last_name='Doe'

// concatenation
String query = "SELECT * FROM Person p WHERE p."
		+ property + " = '" + value + "'";

// formatting
String query = "SELECT * FROM Person p WHERE p.%s = '%s'"
		.formatted(property, value);

They're all a bit cumbersome, though, but that's not even their main drawback. In most cases, we're not creating text for people to read but structured text for other systems, like HTML, JSON, SQL, etc. - and blindly concatenating strings and variables can not only easily create invalid strings, in cases like SQL it can even lead to vulnerabilities. String templates aim to rectify both of these problems.

They make inserting variables and expressions into strings much easier by introducing a syntax to do just that. When creating a one-line string or a text block, simply use \{ as opening and just } as closing delimiter for the expression you want to embed. Using the otherwise illegal sequence \{ ensures that no existing string is suddenly interpreted as an interpolation and serves as an easy differentiator between strings and string templates.

//                                 VARIABLES    ↓↓↓    AND    ↓↓↓
var query = "SELECT * FROM Person p WHERE p.\{property} = '\{value}'";

Because here's the thing: Such a stringy-looking construct won't actually be an instance of String but of TemplatedString.

// ↓↓↓ NOT A STRING!
TemplatedString query = "SELECT *  [...]  p.\{property} = '\{value}'";

To turn a templated string into a regular string, you need a policy and that policy will be domain-specific: Dealing with JSON? Use a JSON policy. Dealing with SQL? Use an SQL policy. And so on.

// ↓↓↓ STRING  ↓↓↓ POLICY
String query = SQL."SELECT * FROM  [...]  p.\{property} = '\{value}'";

The policy will be able to validate the string and make sure it's formed as expected. And even better, it doesn't have to return a string. When you're already parsing JSON or SQL to validate it - why not turn it into a JSON node or SQL statement? Right, no reason not to! So policies allow that as well!

// alternative policy that creates java.sql.Statement
Statement query = SQL."SELECT * FROM [...] p.\{property} = '\{value}'";

I'm pretty exited about that feature! And at JavaOne, Gavin Bierman and Jim Laskey from the Java Platform Group will tell us all about it in their talk String Template Pondering.

Deserialization Filter

There are quite a few sessions on security, but the one I want to recommend the most is the Java Security Q&A with JPG security experts Sean Mullan and Brad Wetmore. If you have any questions regarding security in Java, be sure to ask them there!

But there are a lot of other promising talks as well. For example Brian Vermeers Deserialization Exploits in Java: Why Should I Care? - I'll leave it to him to explain why you should, but assuming you do, I can show you a little bit what you can do against them - Brian will fill in the details.

Java 9 introduced a deserialization filter, a mechanism that you can use to limit what bytestreams will be deserialized. You can create allow-lists and deny-lists for class names and class name patterns, you can limit the object graph's depth and the number of internal references as well as array size and input stream length. If an input stream violates these requirements, it will be rejected and often quickly.

maxdepth=value: maximum depth of graph
maxrefs=value: maximum number of internal references
maxarray=value: maximum array size allowed
maxbytes=value: maximum number of bytes in the input stream

You can statically configure the filter for all deserializations with the system property jdk.serialFilter or the security property of the same name in the JDK file conf/security/java.security. Alternatively, you can dynamically create ObjectInputFilter instances at run time and set them on the respective ObjectInputStream instances. Since Java 17, you can also configure a JVM-wide filter factory to reach those places where you don't control the ObjectInputStream and that are tough to configure with the global option - with it, you can create filters specifically for the context in which they will be applied. If your app uses serialization, I recommend to closely read the secure coding guidelines and also attend Brian's talk - there are links to both below.

// -Djdk.serialFilter=maxdepth=5

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter("maxdepth=5");
ObjectInputStream inputStream = new ObjectInputStream(new ByteArrayInputStream(serializedList));
inputStream.setObjectInputFilter(filter);

Other practical talks on the topic of security are Security Vulnerabilities for Java Developers by Okkta's Brian Demers and Secure Coding Guidelines for Java SE by JPG's Chris Ries. To get a glimpse behind the scenes, check out Weijun Wang's and Sean Mullan's session Evolving the Security of the Java Platform.

Performance

There will be tons of talks on Java performance, from ZGC (twice actually) to G1, from the Vector API to a general performance benchmarking introduction, from JDK Flight Recorder to Micrometer. And almost all of them by the folks working on and improving these very technologies day in day out! So if you have questions about these technologies, this is the place to ask them.

Derived Bindings in JavaFX 19

As an ardent Linux user, I'm living in the perpetual year of Linux on the desktop and so I'm glad that Java's not standing still there either. JPG's desktop veteran Kevin Rushforth will explain in JavaFX 19 and Beyond how the desktop technology improved in recent releases. There's a number of new features and improvements:

JavaFX Media now has support for H.265 - that's a codec important for 4k videos
JavaFX Webview now supports transparent backgrounds
and there are now convenience methods that make JavaFX more approachable

But the one I want to focus on here is the new support for creating derived bindings directly from ObservableValue. Say you're creating an editor for an Employee instance and it has a salary slider. At that point you probably have an observable for the current employee you're editing and another for the salary slider but you want to bind them in a way that when the employee changes, the salary slider is bound to the new employee's salary. This is where derived bindings come in. ObservableValue gets methods map and flatMap that allow you to create new observables for specific properties of a value.

// goal: setting a new `Employee` updates `slider` to their salary
ObservableValue<Employee> employee = new SimpleObjectProperty<>();
ObservableValue<Number> salary = employee.map(Employee::salary);

var slider = new Slider(0, 10_000, 0);
slider.valueProperty().bind(salary);

Note:

That may sound as if moving the slider would update the salary. After all, why else use a slider?! But that's not the case: ObservableValue::map and flatMap return ObservableValue, but bidirectional binding requires a more specific subtype (Property), so that's not possible. Too bad.

End Note.

Beyond this talk, Kevin will give a more general one called Building and Deploying Java Client Desktop Applications with JDK 17 and Beyond together with JPG's Phil Race and there'll be another one on JavaFX by Paul and Gail Anderson. To better understand how to ship such apps, check out Alexey Semenyuk's talk jpackage: Packaging Tool for Java Applications. And if you're a MacOs enthusiast, don't miss Project Lanai - New graphics pipeline for macOS.

Cloud

I'm the first to admit that I don't know much about cloud stuff, but if I wanted to change that - I don't think I wanna, though - JavaOne would be the place to do that. Graeme Rocher from the Graal team will give a talk Zero to Hero, where he live-codes microservices from IDE to cloud with GraalVM and Micronaut. That would probably be a good introduction. As would Modern Java App Development in the Cloud by Rustam Mehmandarov and Mads Opheim from Computas, where they talk about MicroProfile, Quarkus, and serverless. For the more advanced, there's Delightful integration tests with Testcontainers by AtomicJar's Oleg Šelajev and Secrets of Performance Tuning Java on Kubernetes by Bruno Borges from Microsoft.

And since I love podium discussions, I also want to recommend the Java in Containers birds-of-a-feather session with JPG's Larry Cable and Ioi Lam, where they will discuss challenges with tools like Docker, Podman, or Kubernetes as well as practices that can help you solve them.

Outro

And that's it for today on the Inside Java Newscast. Don't forget to check out oracle.com/javaone and I hope I get to see you in Las Vegas in October! Other than that, do all the YouTube things and I'll see you again in two weeks. So long...

Watch the video.

Sequenced Collections, Purity, and more at JavaOne - Inside Java Newscast #31

Nicolai Parlog — Thu, 11 Aug 2022 00:00:00 GMT

Sequenced collections introduce an abstraction for collections with a known encounter order like all lists and some sets and maps. It will be easy to add, get, or remove the first and last elements and to iterate or stream in reverse order. We're also discussing immutable collections and pure functions. More on all of this at JavaOne!

Intro

Welcome everyone to the Inside Java Newscast, where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna look at sequenced collections and the meaning of immutability and purity. And in an unprecedented move, I can already share next episode's topics, too: That will be string templates, the deserialization filter, and JavaFX 19.

Why so random? All of these topics will be presented in a lot of depth at JavaOne and in this episode and the next I wanna give you a sneak peek of what's gonna go down in Las Vegas from October 17th to 20th. It's a unique opportunity to meet the members of JPG, that's the Java Platform Group at Oracle, and chat with them personally - whether it's Brian Goetz, Stuart Marks, Ron Pressler, they and many, many others will be there. To learn more, go to oracle.com/javaone and keep in mind that there's a 200 $ discount if you register before August 14th.

Speaking of URLs, though, I will link to all the sessions that I mention in the description. But! They're not all online yet, so some of the URLs are just my guesswork. I hope you forgive me that this peek is so sneaky, I even tricked Oracle. No doubt, all info will be published soon, but until then, everything I say is subject to change.

With all of that out of the way, are you ready? Then let's dive right in!

Collections

Some people say, Java moves slowly. I say, we got the collections framework in 1998 and 💥 25 years later, List gets methods getFirst() and getLast() - who's slow now? Jokes aside, this was long overdue but better late than never.

Sequenced

To go into a bit more detail: What is going to be introduced, hopefully next year, will be the concept of sequenced collections. This is basically an upgrade form collections with encounter order, which includes all lists as well as some sets, like SortedSet implementations, and some maps, like LinkedHashMap. Importantly, this concept will be captured by three new interfaces: SequencedCollection, SequencedSet, and SequencedMap. And these interfaces will describe methods like get/add/remove first and last.

var j1 = List.of("java", "one");
var java = j1.getFirst();
var one = j1.getLast();

They will also make it much easier to iterate in reverse order by offering a method reversed that returns an instance of the same sequenced interface type that is a view on the current collection but in different direction. That way, you can easily and cheaply use all iteration mechanisms, be it a for-each loop, a stream, a conversion to an array, etc.

// method on `SequencedCollection`
public SequencedCollection<E> reversed();

// easy for loop
for (var e : collection.reversed())
	process(e);

// easy stream
collection
	.reversed().stream()
	.map(Element::getThing)
	.forEach(this::process);

// easy immutable copy in reverse order
var copy = List.copyOf(collection.reversed());

For more on this, check out Stuart Marks' talk Sequenced Collections or go to his Q&A on collections

Immutable vs Unmodifiable

But we're not done with collections yet! Maurice Naftalin will give two talks on the topic. Return to Planet Collections is based on the upcoming second edition of his classic book "Java Generics and Collections". What I look forward to the most is the "design retrospective distilling 25 years' experience of the framework", for example on the, ehm, copious amount of UnsupportedOperationExceptions that the APIs allow.

But he also has a talk on immutable/unmodifiable collections. So why two terms? It appears that the common understanding for immutability means "immutable all the way down", meaning not only can a list or map not change, the elements it contains can't either. Java objects can be immutable, but only if their class:

cannot be extended
has only final and private fields
has exclusive access to mutable components
and offers no mutators for them

"Immutable" generic collections can do almost all of that but won't generally have exclusive access to mutable components, say the User instances you add to them, and can't limit elements to only immutable ones.

var user = new User("Alice");
var users = List.of(user);

// `users` contains user "Alice"

user.setName("Eve");

// now `users` contains user "Eve"
// but isn't it "immutable"? 🤔

Hence a new term is needed - unmodifiable: You can't add, remove, replace, reorder, etc. elements of unmodifiable collections, but the elements themselves could be mutated if they allow it. For more on that, check out Maurice's talk Is Change Inevitable?.

Functional / Data-Oriented Programming

On the theme of immutability, here's one of Venkat Subramaniam's Java functional programming idioms. In his talk on this topic he'll explain what it means for a function to be pure and why that's important.

A pure function is one that has no side effects, meaning it doesn't change any state, and is idempotent, meaning it always returns the same result for the same input. To achieve that, the function can't change anything, that much is obvious, but it also can't depend on anything that may possibly change.

When writing a lambda, Java doesn't help you a whole lot with these two requirements. It gives you a compile error when variables in a lambda body aren't effectively final, which means you cannot reassign those variables inside or outside the lambda, but it doesn't prevent you from taking an effectively final variable and mutate its state, like adding something to a modifiable list for example. Code that does this cannot reap all the functional programming benefits like carefree lazy evaluation and parallel computation.

// using an array to work around that
// pesky "effectively final" rule
int[] factor = { 2 };
var stream = Stream
	.of(1, 2, 3)
	.map(number -> number * factor[0]);
factor[0] = 0;

// "0 0 0" or "2 4 6"?
stream.forEach(System.out::println);

It also makes it tougher to quickly predict what the code does. Check out this example - what does the code print? Make a prediction, try it out in JShell, and let me know in the comments whether you got it right. But the lesson is not, "learn how this code behaves", it's "don't write this code"!

For more functional programming idioms, attend Venkat's talk. And to get more perspectives on functional and data-oriented programming in general, also check out The Sincerest Form of Flattery by my colleague Jose Paumard and by Maurice Naftalin and Data-Oriented Programming with Records, Sealed Classes, Text Blocks, and More by JPG's Brian Goetz and Gavin Bierman. For a sneak peek on data-oriented programming, watch Inside Java Newscast #29 - right after this one.

Project Loom - Virtual Threads & Structured Concurrency

Project Loom took the stage by storm this year. With its two major components, virtual threads and structured concurrency, previewing in Java 19, everybody wants to learn more about it and JavaOne delivers. From a talk by Mr. Virtual Thread himself, Ron Pressler, to a performance review by Java Performance Engineer in JPG Sergey Kuksenko, from experience reports on a Loom-based web server by Helidon's Tomas Langer and a Loom-based implementation of the consensus protocol Raft by Andrii Rodionov to a hands-on lab by Jose, there will be enough to quench your thirst for Loom knowledge and then some. If, by any chance, some questions are left unanswered, there will also be opportunities to talk to all these experts one on one and ask them yourself.

But just between you and me. If you can't make it to to JavaOne, check out Jose's recent JEP Cafe episodes, where he goes all in on virtual threads and structured concurrency - there's a ton of theoretical and practical knowledge in those. Won't give you everything the sessions will be about and I can't give you Ron's telephone number for a remote one-on-one, either, but it will get you a long way.

Misc

But there's so much more than I can possibly cover. As I already mentioned, I'll tell you about string templates, the deserialization filter, and JavaFX 19 in the next episode. Those talks aside, here are a bunch of sessions by subject matter experts that look really interesting.

Speaking of experts, an essential part of conferences is that you not only get to listen to their presentations but also have a chance to chat to them and ask your questions directly. This is particularly noteworthy because at JavaOne you don't have to make due with Billy, Jose, or me, but can talk to members of the Java Platform Group who actually design and create this stuff themselves - because no matter how hard we try, we can never even get close to how much these folks know. So if you have the opportunity to come to Las Vegas in October, you don't want to miss it!

Outro

And that's it for today on the Inside Java Newscast. Don't forget to check out oracle.com/javaone and I hope I get to see you in Las Vegas in October. Other than that, I'll see you again with in two weeks. So long...

Watch the video.

Java Q&A - Inside Java Newscast #30

Nicolai Parlog — Thu, 28 Jul 2022 00:00:00 GMT

We asked you for questions on YouTube, Reddit, and Twitter and are here to answer a bunch of them. From projects Amber to Valhalla, Leyden to Lilliput, from language to performance, from the immediate future to pipe dreams we covered a lot of ground.

This episode was not scripted and so there's no written version of what we said - you really gotta watch this one. 😉

Here are links to the chapters and all other sources (basically the video description):

Watch the video.

Data-Oriented Programming - Inside Java Newscast #29

Nicolai Parlog — Thu, 14 Jul 2022 00:00:00 GMT

Data-oriented programming focuses on modeling data as data (instead of as objects). Records for data and sealed types for alternatives let us model immutable data where illegal states are unrepresentable. Combined with pattern matching we get a safe, powerful, and maintainable approach to ad-hoc polymorphism that lets us define operations on the data without overloading it with functionality.

Intro

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna learn about data-oriented programming. Well, I learned about it a few days ago in Brian Goetz's article "Data Oriented Programming in Java" and now I want to share that with you. In fact, Brian put most things so well, that I'll often just say his words out loud.

So let's see what DOP is all about, how it uses new language features like records and pattern matching to shape our code, and how it relates to OOP, object-oriented programming, that is. I'll start at the deep end and come to the motivation later so hold your "But Objects" comments until the end. Ok? Then let's dive right in!

Data-Oriented Programming

Data-oriented programming is a relatively new term and, by the way, totally unrelated to data-oriented design, so keep those two apart. It encourages us to model data as immutable data, separating it from the domain logic that acts on it. It hinges on sealed types and records, the combination of which is called algebraic data types (ADT for short), to express data and pattern matching to add behavior to it.

Brian formulates four principles:

Model the data, the whole data, and nothing but the data. Records should model data. Make each record model one thing, make it clear what each record models, and choose clear names for its components. Where there are choices to be modeled, such as "a search can result in no match, an exact match, or a few fuzzy matches", model these as sealed classes, and model each alternative with a record. Behavior in record classes should be limited to implementing derived quantities from the data itself, such as formatting.
Data is immutable. If we want to model data, we should not have to worry about our data changing out from under us. Records give us some help here, as they are shallowly immutable, but it still requires some discipline to avoid letting mutability inject itself into our data models.
Validate at the boundary. Before injecting data into our system, we should ensure that it is valid. This might be done in the record constructor (if the validation applies universally to all instances), or by the code at the boundary that has received data from another source.
Make illegal states unrepresentable. Records and sealed types make it easy to model our domains in such a way that erroneous states simply cannot be represented. Just as immutability eliminates many common sources of errors in programs, so does avoiding modeling techniques that allow us to model invalid data.

So that's Brian's four principles for data-oriented programming in Java. Let's put these into practice!

In Practice I

Let's start with something simple. Say you have a method that returns a result, say a User, but sometimes there isn't one - what should be the return type? Of course it could just be User and we return null to signal absence, but that's error-prone and frustrating.

public User findUser(String id) {
	// ...
}

// elsewhere
var user = findUser(id);
if (user != null) {
	// process `user`
}

Alternatively, we could create a wrapper type that contains the user if there is one. That wrapper would need to expose a method to get the potential user and a boolean flag to check its presence first. Maybe you've seen a type like that. It would work ok-ish but the requirement to first check presence and then get isn't enforced by the API and could, potentially, lead to people just calling get and then getting hit by exceptions. Maybe you've seen that happen, too.

class Optional<T> {

	private final T value;

	public Optional(T value) {
		this.value = value;
	}

	public T get() {
		if (value == null)
			throw new RuntimeException();
		else
			return value;
	}

	public boolean isPresent() {
		return value != null;
	}

}

public Optional<User> findUser(String id) {
	// ...
}

// elsewhere
var user = findUser(id);
if (user.isPresent()) {
	// process `user.get()`
}
// oopsie
user.get()

Let's try something else. Brian said we should use sealed types to express alternatives, so we make Optional a sealed interface with two implementations:

None - a record without components
Some - a record with the present value as its only component

sealed interface Optional<T> { /* no `get()` */ }
record None<T>() implements Optional<T> { }
record Some<T>(T value) implements Optional<T> {
	// constructor needs to null-check `value`
}

public Optional<User> findUser(String id) { /* ... */ }

// elsewhere
var user = findUser(id);
user.get(); // compile error - no method `Optional::get`
if (user instanceof Some(User u)) // only this works
	// use `u`

Note that Optional no longer offers a method to get a value that I can call without checking for presence first. Now, to get access to the value, I have to do a type check and unlike the check for presence I can't forget that. So the API contract "check presence then get" was lifted into the type system by expressing the two alternatives of "value" and "no value" as types instead of a boolean flag. Too bad that we can't get this Optional, but since we can also mostly avoid isPresent-then-get with Optional's functional API, which is why I like it so much, I will cope.

In Practice II

We can apply that same pattern to a more complex example. Say we have an API that looks some entities up by a property, say users by name, and distinguishes between "no match found", "exact match found", and "no exact match, but there were close matches." In the interest of time, I'm glossing over the step where I try to cram these alternatives into a single type. You can see it here and it works but it's not pretty.

class MatchResult<T> {

	private final MatchResultType type;
	private final T match;
	private final List<FuzzyMatch<T>> matches;

	// private constructor and factory
	// methods for the three result types

	// accessors that throw exception
	// when no such result
}

enum MatchResultType { NONE, ONE, FUZZY }
record FuzzyMatch<T>( value, int rank) { }


MatchResult<User> findUser(String name) {
	// ...
}


// elsewhere
var r = findUser(name);
// be careful not to just call `r.match()` or
// `r.matches()` without checking `r.type()`!
switch (r.type()) {
	case NONE -> processNoMatch();
	case ONE -> processMatch(r.match());
	case FUZZY -> processMatches(r.matches());
}

The better solution is to once again create a sealed interface, MatchResult, with an implementation for each case, NoMatch, ExactMatch and FuzzyMatch. If we encountered this return hierarchy while browsing the code or the Javadoc, it's immediately obvious what this method might return and how to handle its result. While such a clear encoding of the return value is good for the readability of the API and for its ease of use, such encodings are also often easier to write because the code virtually writes itself from the requirements.

sealed interface MatchResult<T> { }
record NoMatch<T>() implements MatchResult<T> { }
record ExactMatch<T>(T match) implements MatchResult<T> { }
record FuzzyMatches<T>(List<FuzzyMatch<T>> matches)
	implements MatchResult<T> { }
record FuzzyMatch<T>(T value, int rank) { }


MatchResult<User> findUser(String name) {
	// ...
}


// elsewhere
var r = findUser(name);
// no way to accidentally call `r.match()` or
// `r.matches()` - there are no such methods!

// also, we don't even need `r`:
switch (findUser(name)) {
	case NoMatch() -> processNoMatch();
	case ExactMatch(var user) ->
		processMatch(user);
	case FuzzyMatches(var matches) ->
		processMatches(matches);
}

In Practice III

For the last example, let's model something that's more akin to an application-specific domain: an arithmetic expression with variables. Such expressions are best modeled as trees where each inner node is an operation, like addition or multiplication, and the leaves are numbers or variables.

x² + 2x

   +
 ┌─┴─┐
exp  *
┌┴┐ ┌┴┐
x 2 2 x

Even without sealed types and records, we'd probably all model that as an interface Node with specific implementations for each operation and value.

interface Node { }

class AddNode implements Node {
	// with fields `Node left`, `Node right`
}
class MulNode implements Node {
	// with fields `Node left`, `Node right`
}
class ExpNode implements Node {
	// with fields `Node node`, `int exp`
}
class NegNode implements Node  {
	// with field `Node node`
}

class ConstNode(double val) implements Node {
	// with field `double val`
}
class VarNode(String name) implements Node {
	// with field `String name`
}

// x² + 2x
var expr = new AddNode(    //       +
	new ExpNode(           //   exp─┤
		new VarNode("x"),  // x ─┤  │
		new ConstNode(2)), // 2 ─┘  │
	new MulNode(           //    * ─┘
		new ConstNode(2),  // 2 ─┤
		new VarNode("x"))  // x ─┘
);

Now say you want to evaluate such an expression. It stands to reason that an evaluate method on Node would be a good way to do that. But maybe we also want to evaluate subexpressions in parallel, on the same machine or maybe in a small cluster - are that two more methods? We also want to differentiate. And format. And estimate computation time and resource use. Bill users for their computations that they run on our engine. That's a lot of very diverse functionality to add to our nice little Node interface.

// 🤔
interface Node {
	double evaluate();
	double evaluateParallel();
	double evaluateInCluster();
	Node differentiate(String var)
    void draw(Direction d, Style s, Canvas c);
    Resources estimateResourceUsage();
    Invoice createInvoice(User u);
}

But thanks to the power of algebraic data types and pattern matching we don't have to do that. Make Node sealed, turn the implementations into records and use pattern matching in methods outside of these types to add functionality. Here are a few of those that I mentioned earlier.

sealed interface Node { }

record AddNode(Node left, Node right) implements Node { }
record MulNode(Node left, Node right) implements Node { }
record ExpNode(Node node, int exp) implements Node { }
record NegNode(Node node) implements Node { }

record ConstNode(double val) implements Node { }
record VarNode(String name) implements Node { }


// operations
double evaluate(Node n, Function<String, Double> vars) {
    return switch (n) {
        case AddNode(var left, var right) ->
			evaluate(left, vars) + evaluate(right, vars);
        case MulNode(var left, var right) ->
			evaluate(left, vars) * evaluate(right, vars);
        case ExpNode(var node, int exp) ->
			Math.exp(evaluate(node, vars), exp);
        case NegNode(var node) ->
			-evaluate(node, vars);
        case ConstNode(double val) -> val;
        case VarNode(String name) -> vars.apply(name);
    }
}

Node differentiate(Node n, String v) {
	return switch (n) {
		case AddNode(var left, var right) ->
			new AddNode(
				differentiate(left, v),
				differentiate(right, v));
		case MulNode(var left, var right) ->
			new AddNode(
				new MulNode(
					left,
					differentiate(right, v)),
				new MulNode(
					differentiate(left, v),
					right));
		case ExpNode(var node, int exp) ->
			new MulNode(
				new ConstNode(exp),
				new MulNode(
					new ExpNode(node, exp-1),
					differentiate(node, v)));
		case NegNode(var node) ->
			new NegNode(differentiate(node, var));
		case ConstNode(double val) ->
			new ConstNode(0);
		case VarNode(String name) ->
			name.equals(v)
				? new ConstNode(1)
				: new ConstNode(0);
	}
}

double cost(Node n) {
    return switch (n) {
        case AddNode(var left, var right) ->
			1 + cost(left) + cost(right);
        case MulNode(var left, var right) ->
			2 + cost(left) + cost(right);
        case ExpNode(var node, int exp) ->
			exp + cost(node);
        case NegNode(var node) -> cost(node);
        case ConstNode(double val) -> 0;
        case VarNode(String name) -> 0;
    }
}

Before we had records and pattern matching, the standard approach to writing code like this was the visitor pattern. Pattern matching is clearly more concise than visitors, but it's also more flexible and powerful. Visitors require the domain to be built for visitation, and imposes strict constraints; pattern matching supports much more ad-hoc polymorphism. Crucially, pattern matching composes better: We can use nested patterns to express complex conditions that can be much messier to express using visitors.

Node differentiate(Node n, String v) {
	return switch (n) {
		case AddNode(var left, var right) ->
			new AddNode(
				differentiate(left, v),
				differentiate(right, v));

		// special cases of k*node or node*k
		case MulNode(var left, ConstNode(double val) k)
			-> new MulNode(k, diff(left, v));
		case MulNode(ConstNode(double val) k, var right)
			-> new MulNode(k, diff(right, v));

		case MulNode(var left, var right) ->
			new AddNode(
				new MulNode(
					left,
					differentiate(right, v)),
				new MulNode(
					differentiate(left, v),
					right));
		case ExpNode(var node, int exp) ->
			new MulNode(
				new ConstNode(exp),
				new MulNode(
					new ExpNode(node, exp-1),
					differentiate(node, v)));
		case NegNode(var node) ->
			new NegNode(differentiate(node, var));
		case ConstNode(double val) ->
			new ConstNode(0);
		case VarNode(String name) ->
			name.equals(v)
				? new ConstNode(1)
				: new ConstNode(0);
	}
}

Versus Object-Oriented Programming

Now that we've seen the principles and some examples, let's discuss why we'd want to write code like that - doesn't look particularly object-oriented to me! Object-oriented programming is at its best when it's defining and defending boundaries: maintenance boundaries, encapsulation boundaries, compilation and compatibility boundaries, etc. Dividing a large program into smaller parts with clear boundaries helps us manage complexity because it enables modular reasoning - the ability to analyze one part of the program at a time, but still reason about the whole. It's essential when modeling complex entities and when creating rich libraries, powerful frameworks, and large programs.

But programs have gotten smaller and within a small service, there is less need for internal boundaries. At the same time, a smaller service has a larger surface area, relatively speaking, so it'll require more code dealing with data from or for the "outside world" where we can't count on it fitting cleanly into Java's type system. So overall, there's a trend that increases the share of problems for which OOP isn't the optimal solution.

So when we're building simpler services or subsystems that process plain, ad-hoc data, often involving the outside world, the techniques of data-oriented programming may offer us a straighter path. Importantly, DOP and OOP are not at odds; they are different tools for different granularities and situations. We can freely mix and match them as we see fit.

Outro

And that's it for today on the Inside Java Newscast. For more theory and practice on data-oriented programming in Java read Brian's article - link in the description. Leave a comment, like the video, share it with your friends and enemies, I'll see you again in two weeks. So long...

Watch the video.

What is OpenJDK? - Inside Java Newscast #28

Nicolai Parlog — Thu, 30 Jun 2022 00:00:00 GMT

What's "OpenJDK" (or "the OpenJDK"?), how does it work, and what does it do? Here's the answer to these questions as well as explorations of JDK Enhancement Proposals, the Java Community Process, why there are so many JDK providers, and how long-term support works.

Intro

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna clear up the confusion around what the heck OpenJDK really is. Can you download it? Does it have long-term support? Is it dangerous for your kids?

Now that openjdk.org is live, we need to answer these questions. As usually, tons of links in the description - let's dive right in!

OpenJDK

We'll start with the very basics: What's OpenJDK? Or is it the OpenJDK? No, it's not. It's either the OpenJDK Community or just OpenJDK - the two are synonymous. It's a place where a community of individuals work together on the JDK project to create the open source reference implementation of the Java Platform, Standard Edition as well as related projects. Let's explore that a bit.

Place For A Community

As I said, OpenJDK is a community of individuals, so there are no companies. Oracle, RedHat, Microsoft - they don't exist here. Well, there's one exception - I'll call it out when I get to it.

So OpenJDK has to govern itself and it does that according to its bylaws. They define the overall structure and processes, roles, voting mechanisms, stuff like that. And it's not very long - about 4.500 words, so about 20 minutes to read out loud. clears throat

Preamble The OpenJDK Community is...

So, to summarize, the OpenJDK community is structured as a set of groups (that are individuals around topics like the compiler or tooling) and a set of projects (that are collaborative efforts to create specific artifacts, like the project that works on JDK 19 or Project Amber). There are community-wide roles (Participant, Contributor, and Member) as well as roles specific to Groups (Member and Lead) and to Projects (Author, Committer, Reviewer, and Lead).

Take Stuart Marks, for example. He's a member of OpenJDK itself and the core-libs group, reviewer on jdk, jdk-updates, and a few more and committer on a lot more projects like Panama and Valhalla. Busy guy. You can look that up in the census, by the way, which, yes exactly, I'll link in the description below.

Another important role in the OpenJDK community plays the governing board. It manages OpenJDK's structure and operation and consists of five contributors:

the Chair, appointed by Oracle: Georges Saab
the Vice-Chair, appointed by IBM: Annette Keenleyside
the OpenJDK Lead, appointed by Oracle: Mark Reinhold
two elected Members who serve for one year: at the moment, these are Andrew Haley from RedHat and Volker Simonis from Amazon

This was it, by the way! The only place in OpenJDK where companies play a role is Chair, Vice-Chair, and OpenJDK Lead.

And that covers the community, now let's turn to what they're actually working on.

The JDK Project

The OpenJDK community collaborates on a number of projects, most importantly the JDK Project, which is always lead by the OpenJDK Lead, so Mark Reinhold. That's the code base that contains ArrayList, javac, HotSpot, etc. It's hosted on GitHub under openjdk/jdk. But the JDK project also controls the release repos, like jdk18 and jdk19, until they become generally available. When that happens, when the Java Community Process spits out another version of Java SE, OpenJDK tags a commit in the corresponding fork... and abandons it.

Because maintenance is the task of another project, namely JDK Updates. It controls the update repos, like jdk18u and jdk19u, and project lead Rob McKenna from Oracle leads maintenance for six months before passing the baton to a qualified OpenJDK member if one steps up. So far, that has been the case for all odd-numbered releases since 10 - they all see regular merges and release tags.

There are way more projects, though, and you can find all of them in the census and all of their repos under the GitHub org openjdk. Projects like Amber and Loom usually get one or more repos, and ZGC and Shenandoah also each have one, and then there are repos for tools like jextract and Java Mission Control.

Java Enhancement Proposals

Each OpenJDK project governs itself and as the most important one, the JDK Project has the most formal process. A key part of that are the famous JDK Enhancement Proposals, JEPs for short. A few exceptions aside, each is an effort to design and implement a nontrivial change to the JDK code base.

There's a ton more that could be said about JEPs, for example their workflow, how they relate to projects, how they form the JDK roadmap, and much more. Since this episode focuses on OpenJDK, though, that would be a massive side track. And I already read the full bylaws, so we're way over time anyway. But if you're interested to learn more about the JDK development process, let me know in the comments, and I'll gladly discuss that in a future episode. That's also a good opportunity to subscribe and turn on notifications, so you don't miss that video.

That's it?!

Indeed, that's it! The Java Community Process, Java Specification Requests, binaries, distributions, vendors, long-term support - none of that is part of OpenJDK. All of that are projects, processes, and organizations that work in parallel or on top of OpenJDK. You can't download "the OpenJDK" because it produces no binaries - in case you wondered why I didn't talk about them, it's because there aren't any. And while I've technically fulfilled my promise to tell you about OpenJDK, you'd probably feel short-changed if I left it at that, so let's touch on at least a few of those, namely the Java Community Process, why we have so many JDK distributions, and what's up with long-term support.

NOT OpenJDK

Java Community Process

The Java Community Process, or JCP for short, is its own beast that I can't do justice in a minute or two, but the tagline is: It's the mechanism for developing standard technical specifications for Java technology. Think of the Java Language Specification, for example. So the JCP produces specifications that OpenJDK then provides the reference implementation for.

The JCP's main vehicle is the Java Specification Request (JSR). In the past, we had lots of those, enshrining the changes proposed by large projects like Lambda and Jigsaw, but with the move to the faster release cadence and piecemeal delivery of features, nowadays there's mostly just one JSR for each Java release. The one for Java SE 19, for example, is JSR 394.

Each JSR has at least one Specification Lead, for 394 those are Iris Clark and Brian Goetz, and for it to be released, one of their tasks is to provide a binary with the reference implementation. So when the Java Community Process finalizes another version of Java SE, which technically is just an abstract platform as defined by the specification, the respective spec lead provides the reference implementation, a concrete and runnable JDK, built from the corresponding OpenJDK project.

These binaries, one for Linux and one for Windows, receive no updates and are not production-ready! They serve as a reference for all implementors of the specification, like a kilogram weight sample in a museum, for example. They are published under GPL version 2 with Classpath Exception under jdk.java.net/java-se-ri/$VERSION, which is different from jdk.java.net/$VERSION that you're probably familiar with. Let's get to those!

Binaries, Distributions, Vendors

Early access builds for OpenJDK projects, like Loom and Valhalla, can be created by anybody and Oracle often does that but so do others. As I just explained, reference implementations are created by the spec leads. But what about those under jdk.java.net/$VERSION?

Those are Oracle's builds of the jdk$VERSION Project in OpenJDK - or Oracle OpenJDK builds for short. Remember when I said Rob McKenna leads each JDK Update repo for six months? During those six months, Oracle distributes its OpenJDK builds under GPLv2+CE and they do get updates during that time and are 100% production-ready, always the freshest features right out of the oven. Definitely my choice of JDK!

But Oracle also offers Oracle JDK, no Open in that name - as-is for free under its NFTC license or as part of the Java SE subscription if you need proper support. Oracle builds these from internal repos that are mostly mirrors of the corresponding OpenJDK update repos, but can contain slightly different or additional patches. And that's pretty much what most or even every other vendor does as well - they maintain mirrors of the update repos plus their own patches. Many give their binaries away for free and then also offer commercial support for those who need it.

I know that this can get confusing. Why are there so many build providers? How do they differ? And how to select vendors?

Well, like with Linux, there are multiple build providers because OpenJDK is open source and there are that many because the Java ecosystem is so large that all of these companies reckon they can earn good money - which is good because I'm not sure whether you've noticed but what I've described so far is pretty time-demanding and almost everybody who works on it does so on company time. If there weren't any money in Java, there'd be no Java.

And how do you select vendors? I really can't help you with that - working for Oracle, I'm clearly biased.

Long-Term Support

Another often confusing issue is that of long-term support, or LTS. What does it mean, who offers it, and how is it implemented, etc.?

As to what that means, that's surprisingly vague. I personally like the distinction between maintained and supported, where maintained means, you get regular updates, often for free, that include all relevant security fixes, and supported means that plus you can yell at someone on the phone if there's an issue. For more details, you have to compare what vendors specifically describe as their service and support.

Because, and I probably should've lead with that, it's the build providers who decide what level of support they want to offer for what version. So the concept of LTS lives outside the realm of JCP and OpenJDK and each company can do whatever they want. And they do, but they also do want to coordinate. Because maintaining a Java release is a lot of work and it gets a bit easier if it's split across more people. That also means, companies have an incentive to upstream their patches and changes to the OpenJDK repo because the closer everybody stays to that, the more they can benefit from the work of others. It's like a positive variant of the prisoner's dilemma, which is pretty impressive if you think about it and a major reason why Java has such a strong and diverse ecosystem.

So when Rob McKenna shifts his focus from leading one update repo to the next, he'll offer the repository lead role for the old one to other JDK Update Project members. And since potential leads and contributors are probably doing their work on company time, I imagine their companies will make a decision what releases they see value in and want to pay for the maintenance of. So the companies' decisions which versions to offer support for impact how many people can invest time into contributing to OpenJDK update repos. And that's why, even though OpenJDK is LTS-agnostic, it's exactly the versions that have commercial support who see continued updates to their source code in OpenJDK after their first six months. Makes sense?

Outro

Uhm, I made a mistake and asked you on Twitter and Reddit for questions about OpenJDK before I wrote this script. So I didn't know how long it would get and how few of your questions I could actually tackle. So here's an idea, what do you think about an episode dedicated to just your questions? About all things Java? That could be fun! Let me know.

And that's it for today on the Inside Java Newscast - do all the YouTube things and I'll see you again in two weeks. So long ...

Watch the video.

Java 19 - The Best Java Release? - Inside Java Newscast #27

Nicolai Parlog — Thu, 16 Jun 2022 00:00:00 GMT

Java 19 is the first release to preview Project Loom's virtual threads and structured concurrency, Project Amber's record patterns, and Project Panama's foreign memory and function APIs. It also continues previews of pattern matching in switch and vector API. Put together, this makes it the most groundbreaking Java release in years and probably for years to come!

Intro

Welcome to Crete, everyone! I'm here on holiday right now, which means I should be sitting on the beach, sipping Gin Tonics and getting sun-burnt, but then I couldn't tell you about the most groundbreaking Java release in recent years and probably for years to come.

Is he talking about Java 19?

Indeed, I am! And thanks for asking, Billy.

You're welcome

Oh, I should probably mention that while I'm in paradise talking to you about Java, Billy is stuck in Kansas, sitting in his room, grumpily editing this episode.

It's actually Missouri

Say "Hi", Billy!

No

Hah, funny man.

Anyway, JDK 19 has been forked last week, so lets go over what code you can write that you couldn't write before and why this makes for a monumental release - let me know in the comments whether you agree. There's lots more to talk about for all of these features, so I'll put plenty of links in the description. Ready? Then let's dive right in!

Pattern Matching in Switch

With a modernized switch, type patterns as the first instance of patterns, and sealed classes in place, Java 19 makes headway on putting them together: Using patterns in switch. This takes a bit more time to shake out all the details and is currently in the third preview.

enum MyBoolEnum { FALSE, TRUE }

MyBoolEnum bool = // ...
int value = switch(bool) {
	case FALSE -> 0;
	case TRUE -> 1;
};

double area;
if (shape instanceof Rectangle r)
	area = r.height() * r.width();

sealed interface Shape
	permits Rectangle, Circle {
	// ...
}

Shape shape = // ...
double area;
if (shape instanceof Rectangle r)
	area = r.height() * r.width();
else if (shape instanceof Circle c)
	Math.PI * square(c.radius());
// no benefits from sealed, yet

Shape shape = // ...
double area = switch (shape) {
	case Rectangle r ->
		r.height() * r.width();
	case Circle c ->
		Math.PI * square(c.radius());
}

A few noteworthy aspects:

Exhaustiveness is not only checked for switch expressions but also for switch statements if they use patterns.
If the switch variable is null, a NullPointerException will be thrown unless a case null handles it.
While using patterns is nice, it doesn't capture all checks you may want to apply to an instance and so when clauses allow you to add additional boolean expressions to refine cases.
This is not just about type patterns, but more generally all kinds of patterns in switch. More patterns introduced in the future will "just work" in switches.

Shape shape = // ...
// must be exhaustive
// (even it it were a statement)
double area = switch (shape) {
	// without this line a null shape
	// would lead to NPE
	case null -> 0;
	// pointless "optimization"
	// to show off `when`
	case Rectangle r when r.height() == 1 ->
		r.width();
	case Rectangle r ->
		r.height() * r.width();
	case Circle c ->
		Math.PI * square(c.radius());
	// because Shape is sealed, compiler
	// knows all cases are covered and
	// no default branch is needed
}

So Java 19 is doing all the right things, like the new requirement of case null for null handling, and I feel it in my old bones, I don't think there'll be a fourth preview. And while finalizing this proposal won't be the end of Java's evolution in this space, it will be an important milestone. We'll finally have all the pieces we need to start using pattern matching in our daily work, in anger as the Brits say!

The Brits?! Don't a lot of people use "in anger"?!

And it also frees up Project Amber for other work, for example on... record patterns.

Record Patterns

Inspecting an instance's type is nice and all, but sometimes you need to reach deep in and special-case the order where the buyer is an employee and not a customer or where the order amount is above a certain threshold. Record patterns let you do all that easily and declaratively by taking apart a record into its constituent components.

Doesn't this violate encapsulation?

Ah, remember that records are all about transparency, so if you want to encapsulate your data, they're not the right choice anyway.

I knew that, but Nicolai forced me to say that

So, when applying an instanceof check in an if or switching over an instance, you can write what looks like the record's canonical constructor to declare variables and assign them the components' values in one go. You don't actually have to use the same names, though. Components are identified by their position and you can give the variables any name you want. And you don't have to use their types either! You can use var to have it inferred or use a subtype to only match those instances whose component has that exact type. This way you can, for example, easily special-case orders whose buyer is an employee.

record Order(Buyer buyer, Items items)
	implements Action { }
class Employee implements Buyer { }
class Customer implements Buyer { }

if (action instanceof
	Order(Employee emp, var items)) {
	// use `emp` and `items`
} else if (action instanceof
	Order(Customer c, Items items)) {
	// use `c` and `items`
}

All this is very exciting! Not only because it's gonna be very handy for handling simple data and is another step to records as full-blown algebraic data types, this preview is also testament to Project Amber's shift towards introducing more patterns! Deconstruction for records, maybe for classes, possibly for destructuring on assignment, we may get custom patterns - so many thrilling options and JDK 19 is taking the first step!

Very exciting

Foreign Function & Memory API

I'm no native code guy, in fact I can't even write C or C++.

He can barely write Java...

So I'm not gonna embarrass myself talking about things that I don't understand. Instead, I'm gonna show you a code snippet of the foreign function and memory API that sorts a string array with the C library function radixsort.

And I'm gonna let Billy talk you through it.

What?!

Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle radixSort = linker
	.downcallHandle(stdlib.lookup("radixsort"), ...);

String[] onHeap   = { "mouse", "cat", "dog", "car" };

SegmentAllocator allocator = implicitAllocator();
MemorySegment offHeap  = allocator
	.allocateArray(ValueLayout.ADDRESS, onHeap.length);

for (int i = 0; i < onHeap.length; i++) {
    MemorySegment cString = allocator
		.allocateUtf8String(onHeap[i]);
    offHeap.setAtIndex(ValueLayout.ADDRESS, i, cString);
}

radixSort
	.invoke(offHeap, onHeap.length, MemoryAddress.NULL, '\0');

for (int i = 0; i < onHeap.length; i++) {
    MemoryAddress cStringPtr = offHeap
		.getAtIndex(ValueLayout.ADDRESS, i);
    onHeap[i] = cStringPtr.getUtf8String(0);
}

Well, this is unexpected. Ok, so, first you'll want to find the foreign function, in this case radixsort, on the C library path. Next, you'll allocate on-heap memory to store the strings. Then you'll allocate off-heap memory to store an equivalent number of pointers. Copy the strings from on-heap to off-heap. So you will want to then sort the off-heap data by calling the foreign function radixsort. And last, copy the new reordered strings from off-heap to on-heap. Ok back to you, Nicolai!

Thank you, Billy!

The APIs have been incubating independently for a few releases and have seen some revamps during that time, but Java 19 probably puts an end to that. It ships them as a preview in their final package and no major changes are foreseeable - another milestone, this time from Project Panama, achieved by 19. Another crucial ingredient is jextract, which recently became a stand-alone project to be evolved more rapidly than the JDK release cadence would allow. There's a link to the GitHub in the description.

Virtual Threads

Plenty has been said about Project Loom's virtual threads, most recently in the latest JEP Cafe that I highly recommend you check out. So I'll keep this super short!

Not short enough...

In all ways that matter, virtual threads behave like platform threads, but are cheap enough that you can have millions and millions more. This gives you the scalability of asynchronous programming models with the simplicity of synchronous code. It can't possibly be that simple? Well, not quite but almost - as I said in the intro, check out the linked sources for more.

try (var executor = Executors
		.newVirtualThreadPerTaskExecutor()) {
	// create one million virtual threads that...
	// do nothing - still, pretty cool!
	for (int i = 0; i < 1_000_000; i++)
		executor.submit(() -> {
			Thread.sleep(Duration.ofSeconds(1));
			return i;
		});
}

Your interaction with virtual threads will likely be very indirect. While there's a new Thread.Builder API and new methods Thread.ofVirtual and Thread.startVirtualThread(Runnable), you probably won't use them very often.

Runnable runnable = // ...
Thread thread = Thread
	.ofVirtual()
	.name("duke")
	.unstarted(runnable);

A good way to start multiple virtual threads is with the Executor that uses a virtual thread per task. And I'll come to an even better way in a minute. But most threads in your app will likely not be created by you but by your web server. And it will hopefully get an option soon to spawn a virtual thread instead of a platform thread for each request, so your code runs in virtual threads by default.

All of this is truly groundbreaking and Java 19 will always be remembered as the release that first previewed Project Loom's core. But they're not done yet - Java 19 isn't, Loom isn't, even Java 19 on Loom isn't!

Structured Concurrency

Loom's other big play is introducing structured concurrency to Java. Its principle is that if a task splits into concurrent subtasks, they all return to the task's code block. Consequently, the lifetimes of all concurrent subtasks are confined to a single syntactic block, which means they can be reasoned-about and managed as a unit.

To that end, the parent task creates a new scope, decides on the error handling it needs, spawns the subtasks, and then awaits their completion. It can process any errors that occurred or, if all went well, compose the subtasks' results to its result.

UserOrder load(long userId, long orderId) throws InterruptedException {
	try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
		// spawn subtasks
		Future<String> user = scope.fork(() -> findUser(userId));
		Future<Integer> order = scope.fork(() -> fetchOrder(orderId));

		// wait for them to complete...
		scope.join();
		// ... and throw errors if any
		scope.throwIfFailed();

		// here, both subtasks succeeded
		return new UserOrder(user.resultNow(), order.resultNow());
	} catch (ExecutionException ex) {
		// handle errors if any
	}
}

Nesting subtasks in a parent's block induces a hierarchy that can be represented at run time when structured concurrency builds a tree-shaped hierarchy of tasks. This tree is the concurrent counterpart to a single thread's call stack and tools can use it to present subtasks as children of their parent tasks. That means your IDE has all the information it needs to let you navigate from any subtask deep in the bowels of your system to parents and their parents all the way up the outermost task, for example the web request that spawned the entire computation.

Virtual threads and structured concurrency together go like, like... Yes, thank you! Virtual threads deliver an abundance of threads and structured concurrency ensures that they are correctly and robustly coordinated. Thanks to that, observability tools will see threads organized in the logical manner intended by the developer. And all of that in Java 19, even if just as a preview!

Peanut butter and Jelly?

Vector API

Look, I know I promised you an introduction to the vector API but today's not a good day for that. I'm running out of time and I really want to get back to those Gin Tonics that I mentioned and... Oh. Well, I guess that covers that. Ok, let's make it quick and do something deeper in the future.

// assume a, b, c have same length
void compute(float[] a, float[] b, float[] c) {
	for (int i = 0; i < a.length; i++) {
		c[i] = a[i] + b[i];
	}
}

In arithmetic-heavy areas like image processing or machine learning it's common to have loops that execute the same computation on all elements of one or more arrays. As a simple example, say you have two arrays a and b of equal length and want to pairwise add their elements. Then the CPU might execute instructions that boil down to

load element from a into a register
load element from b into a register
add the registers
write result to c

Or it might

load 16 elements from a into a multi-word register
load 16 elements from b into another multi-word register
add the registers
write those 16 results to c

Both instruction sets take about the same time but the second version, which uses the CPUs vector extension, computes 16 results instead of 1 - that's a 16-fold speedup! Which one of these instructions it's gonna be depends on whether the just-in-time compiler's auto-vectorizer can figure out what to do with your loop and while it's great when it does that, it can't do it reliably.

The vector API, on the other hand, lets you write computations that reliably translate to optimal machine instructions. It requires a bit more code and a different approach, though. First you create a so-called vector species, which among other things has a length that's the actual multi-word register length, which is different in different CPUs, divided by the length of the data type you want to use, double or float for example. The 16 earlier was just an example, it could just as well be 4, 64, or something else.

Then you write a loop that takes steps of that length, so that in each iteration

you load that many elements from the input arrays into vectors
do the computation BigInteger-style by calling methods on them
then write the resulting vector to the result array

At run time, the just-in-time compiler will create machine code specifically for the CPU that executes this, thus guaranteeing optimal performance on all platforms. Neat, huh?

static final VectorSpecies<Float> VS =
	FloatVector.SPECIES_PREFERRED;

// assume a, b, c have same length,
// which is a multiple of the vector length
void compute(float[] a, float[] b, float[] c) {
	int upperBound = VS.loopBound(a.length);
	for (i = 0; i < upperBound; i += VS.length()) {
		var va = FloatVector.fromArray(VS, a, i);
		var vb = FloatVector.fromArray(VS, b, i);
		var vc = va.add(vb);
		vc.intoArray(c, i);
	}
}

While JDK 19 further improves the vector API, it doesn't take the big step to bring it out of incubation. It's waiting for Project Valhalla's improvements because they will change the API and it would be sad to finalize it now and then in a few years be stuck with a version that could be better but can't be changed anymore.

Speaking of Valhalla, can you imagine how amazing it would be if it also previewed something in 19? In fact, the release that contains those changes is the only one I can imagine to be more groundbreaking than JDK 19. What do you think, would it be better than this one with all that Loom, Amber, and Panama goodness? Let me know in the comments!

Outro

And that's it from Crete! I hope you're looking forward to JDK 19 just as much as I do. Don't forget to like and share with your friends and enemies. I'll see you again in two weeks - so long...

Watch the video.

nipafx

Avoiding Final Field Mutation

Initializing Instances

Ignoring Constructors

Using Constructors

Embracing Constructors

Platform Serialization

Serialization

Limit to Records

Use Records as Proxies

Limit to Serializable

Embrace Constructors

Dependency Injection

Cloning

Non-Construction Cases

You Must Avoid Final Field Mutation - Inside Java Newscast #110

Final Field Mutation

Platform Serialization

Serialization

Require Broken Classes

Limit to Records

Use Records as Proxies

Hook Into Platform Serialization

Embrace Constructors

Dependency Injection

Cloning

Embracing Constructors

Analysing Crashed JVMs - Inside Java Newscast #109

A jcmd Primer

Reviving A Dead JVM's Brain

Example & Limitations

Java 27 - Better Language, Better APIs, Better Runtime

Towards Better Checked Exceptions - Inside Java Newscast #107

Inherited Checkedness

Too Many Checked Exceptions

Catching Unthrown Exceptions

Functional Error Handling and Deferred Computation

Stylistic Changes

Removal of ThreadPoolExecutor.finalize()

Deprecation and Removal of Finalizers

Removal of ThreadPoolExecutor.finalize()

Source-Incompatible Change

LazyConstants in JDK 26 - Inside Java Newscast #106

Laziness

LazyConstant

LazyConstant Behavior

Lazy Collections

API Evolution

Carrier Classes; Beyond Records - Inside Java Newscast #105

Carrier Classes

Record Review

Semantics

API Commitment

Representation

Beyond Records

More Amber Goodies

Java's Plans for 2026 - Inside Java Newscast #104

Project Valhalla

Project Panama

Project Babylon

Project Loom

Interlude

Project Leyden

Project Amber

Java's 2025 in Review - Inside Java Newscast #103

Projects Panama and Loom

Project Babylon

JavaOne

Project Amber

Project Leyden

Java 25

Deprecations

Project Valhalla

All Features in Java 26 - Inside Java Newscast #102

HTTP/3 Support

Improved G1 Performance

AOT Caching With Any GC

Applet API Removal

Reflective Mutation Of Final Fields

Primitive Patterns

Limit to `Serializable`

A `jcmd` Primer

`LazyConstant`

`LazyConstant` Behavior

`DEREncodable` and `PEMRecord`