Value Objects (JEP 401) Returns to Candidate Status
JEP 401, Value Objects, has been reintroduced to Candidate status in the OpenJDK JEP process, restarting the path toward a language feature that has been discussed for years as part of Project Valhalla. Value objects contain only final fields, lack object identity, and are distinguished purely by their field values — a shift from Java's traditional identity-based object model toward something closer to how primitives already behave.
The practical motivation is performance: without identity, the JVM gains freedom to flatten value objects into arrays and pass them without heap allocation or pointer indirection, similar to how a record already avoids some overhead but without Valhalla's deeper layout optimizations. Bringing JEP 401 back to Candidate status doesn't target it at a specific release yet, but signals renewed momentum on one of the most consequential pending changes to the Java object model.
For teams building performance-sensitive code — numeric libraries, data pipelines, anything currently reaching for primitive arrays to avoid boxing overhead — this is worth tracking closely as it moves through Preview stages in upcoming JDK releases.
Read more — InfoQ
WildFly 41 Reaches General Availability
WildFly 41 GA shipped on July 16, 2026, the latest release of Red Hat's open-source Jakarta EE application server. The headline changes are largely operational rather than feature-driven: bootable JARs now ship in the cloud Galleon pack, letting teams produce self-contained deployable artifacts tuned for containerized environments without pulling in the full server distribution.
More significantly, WildFly 41 replaces its JDK 17 base container images with JDK 25 images, aligning the server's baseline runtime with a much more recent LTS release. Teams still running WildFly on JDK 17 containers should plan the migration path, since staying on JDK 17-based images means missing out on the performance and security improvements JDK 25 brings, along with eventual JDK 17 end-of-life pressure.
The release also promotes several features from experimental to stable feature-stability levels, reducing the number of flags needed to run supported configurations in production.
Read more — InfoQ
TornadoVM 5.1.0 Adds 8-Bit Floating-Point Support
TornadoVM, the GPU/FPGA acceleration framework for Java, shipped version 5.1.0 with support for E4M3 and E5M2 8-bit floating-point formats in its CUDA backend. These low-precision float formats — increasingly standard in ML inference workloads — let TornadoVM programs trade numerical precision for substantially reduced memory bandwidth and higher throughput on compatible GPUs.
The release also adds staged host-to-device transfers for the PTX/CUDA backends, reducing transfer latency by overlapping data movement with computation, and includes performance improvements to intra-plan concurrency handling — relevant for pipelines that run multiple TornadoVM task graphs concurrently on the same device.
For Java teams doing GPU-accelerated numerical or ML workloads without leaving the JVM, TornadoVM 5.1.0 narrows the precision-format gap with native CUDA tooling.
Read more — InfoQ
