Oracle software engineer Lois Foltan has confirmed that Java Enhancement Proposal 401 for Value Classes and Objects – part of Project Valhalla – will be integrated into the OpenJDK mainline early next month, targeting JDK 28. Previews of JEP 401 have so far been available only in early-access builds. The current JDK (Java Development Kit) is 26, with JDK 27 expected in September and JDK 28 in March 2027. The next long-term support version is likely to be JDK 29 in September 2027. Foltan said it was an "extremely large change", such that other OpenJDK committers are asked to avoid large commits in order to help a successful integration. The pull request for the first preview of JEP 401 adds more than 197,000 lines of code in 1,816 changed files. Created in August 20222, JEP 401 tackle a longstanding Java limitation: aside from a small number of primitives including int, char, byte and double, all types in the language are reference types. The JEP introduces "value objects" – class instances that lack object identity and are distinguished solely by the values of their fields. A few examples illustrate the problem JEP 401 is trying to solve. Java's LocalDate class stores date values, but every instance gets its own unique reference, so even if two instances represent the same data, comparing them with ==returns false, as they're different objects in memory. LocalDate provides an "equals" method instead.. Another example, even more confusing example is Integer, which wraps an int to provide convenience methods like toString(). Internally, Integer caches instances for values below 128, so two Integer objects with the same small value can compare equal with == but for larger values, == always returns false even when the underlying values match. Due to this quirk, Java editors generally warn against using == with Integer, a pitfall JEP 401 describes as "unwanted complexity." JEP 401 will migrate some JDK classes such as Integer to value classes, and the number of migrated classes is likely to increase gradually. Developers will also be able to create their own value classes. One of the goals of JEP 401 is to give freedom to the JVM (Java virtual machine) to store value objects in ways that maximize performance. The memory footprint of reference types is greater than for reference types, and they must be dereferenced to obtain their values. Iterating over value types is more efficient. Project Valhalla has been so long in the making, thanks to the complexity of the changes, that some onlookers have joked about getting to Valhalla itself (a realm in the afterlife in Norse mythology) before the project is delivered. Oracle's Java Language Architect Brian Goetz said this is "just the first part of Valhalla" and even after the preview is delivered, "the 'but they'll never deliver it' crowd' will quickly switch gears into 'but they haven't delivered the most important part' soon enough.'" Goetz said "there are many things that force us to treat objects with reference semantics. JEP 401 knocks down the first level of these, by taking identity off the table, which exposes a lot of new optimizations, especially for smaller objects. But fully treating objects with value semantics requires giving up more: nullity and atomicity-safety-under-race (ASUR). Lots of languages have, or are working on, ways to get there, (such as C# structs.) "The main challenge is how to package it in the user model so that it doesn't fight with our own preconceived notions of object integrity and encapsulation; classes are, for better and worse, a very effective abstraction barrier." He said that Valhalla will introduce deliberate breaking changes to Java, such as that "code that synchronizes on Integer objects now fails with an exception." Goetz added JEP 401 will still likely be in preview in the next LTS release of the JDK. "Hoping for it to exit preview for 29 seems … optimistic. Vector API should be able to exit incubation when it rebases on the underlying VM primitives from Valhalla ... don’t hope for a shorter-than-usual preview window." ®

HANDS ON At WWDC this week, Apple introduced container machines, which are persistent virtual machines running Linux, bearing some resemblance to Windows Subsystem for Linux (WSL) on Microsoft's operating system. Developers using macOS, as with those on Windows, face the problem that most applications are deployed to Linux, creating a mismatch between the development machine and the deployment target. The friction is less for macOS, which, like Linux, is Unix-like, but still exists. Apple's solution builds on the Container project previewed at WWDC last year. Version 1.0 was released at this year's WWDC, complete with the new container machine feature. The project uses standard Open Container Initiative (OCI) containers, and both the containers and container machines run on lightweight virtual machines (VMs), giving strong isolation. On Windows, WSL is an important tool for developers. Could container machines have a similar impact for Mac devs? There is potential, but Apple has work to do both on features and documentation, and the project is tucked away on GitHub rather than being presented as part of macOS. The code is written in Swift and is open source on GitHub under the Apache 2.0 license. It uses another Swift package called containerization, which is also open source. We tried a brief hands-on, installing the 1.0 release from the GitHub release package on Tahoe 26.5.1. Only macOS 26 is supported. The name "container machine" is intended to convey that the feature combines both a container and a VM. The feature uses Apple's native virtualization framework, and the command line interface integrates well with macOS. Once installed, the command container machine run will open a terminal in the default container machine. Another option is to run a command such as container machine run uname -a, which will execute in the default container machine but without leaving the macOS shell. Once installed, the command container machine create is enabled, though only containers that include the /sbin/init system initialization program will work. Many container images designed for running applications, rather than being used for persistent VMs, do not include this. The solution is to build a custom container image from a Dockerfile, for which the documentation now includes examples. We used the Dockerfile supplied in a tutorial that sets up a container machine based on Ubuntu 24.04 with the Swift SDK included, followed by the steps to develop using Visual Studio Code running on macOS and connecting to the container machine via VS Code remoting. This worked and we were able to build a project on Linux and run it using VS Code and Safari on the Mac side, but debugging breakpoints were not hit. We tried again with a .NET project, for which debugging worked correctly. By default, a container machine mounts the macOS home directory with read-write permissions. This is great for accessing code or other assets from both macOS and the container machine, but not good for security. A rogue package installed on Linux, for example, could easily harvest credentials from a .ssh folder in macOS. This is configurable via the --home-mount argument. Setting access to "none" is more secure. The memory available to a container machine defaults to half the system memory. In our case that is 32 GB, but after launching the VM and starting PostgreSQL, the actual memory used, according to Activity Monitor, was only 1 GB. Additional memory is used on demand, but a limitation described in the technical overview is that memory cannot be released back to the host. In other words, memory usage will increase during use and can only be released by restarting the VM. WSL supports GUI applications via the X11 or Wayland graphic systems. An issue raised by a user about GUI applications in containers was closed on the basis that developers can install XQuartz, a project for running the X windows system on macOS, and then use container-to-host networking to connect, though we did not try this. GUI support appears not to be a goal of the project. Mac developers already have many ways to run Linux containers or VMs, including the mature ecosystem around Docker, Podman, Colima, UTM, VirtualBox, and OrbStack, to mention some contenders, as well as the option of using SSH to connect to a remote Linux VM. That means Apple has some work to do to establish its native container tools, and now container machines, as serious alternatives. On the plus side, the system is lightweight, aside from the inability to release memory, and performed well in our quick hands-on. A WWDC video has further details, alongside the documentation on GitHub. ®