Serguey Asael Shinder: JDK 28 preview makes Integer and LocalDate value classes, and unchanged code feels it

28 October 2026, 09:55 · by Serguey Asael Shinder / Serguey Shinder

The OpenJDK Quality Group has sent a heads-up to the open-source projects in its Quality Outreach programme about JEP 401, which brings value classes to JDK 28 as a preview feature. The note, published on inside.java on 27 October 2026, explains why this preview is unusual: with preview features enabled, 30 JDK classes become value classes, among them the primitive wrappers — Integer, Long, Float, Double, Byte, Short, Character, Boolean — and java.time types such as LocalDate, LocalTime, LocalDateTime, ZonedDateTime, OffsetTime and OffsetDateTime.

That means existing code starts using the new feature without being changed, and the behaviour changes apply when code runs on JDK 28 with previews enabled, even if it was compiled without them or on an older release. Value objects have no identity, so:

• == compares value objects by their field values, so for these JDK classes it may return true where it used to return false;
• they have no monitor — synchronizing on one, or calling wait and notify, is a compile error or an IdentityException;
• the java.lang.ref APIs and WeakHashMap cannot hold them and throw IdentityException;
• their fields are truly immutable, and setAccessible on them fails with IllegalAccessException.

Records are affected separately. When code is compiled with previews enabled on JDK 28, record constructor code runs during early construction by default (the phase finalized by JEP 513), where interaction with this is limited to field assignments. A record constructor that calls an instance method then fails to compile; constructors compiled without previews but run with them execute as compiled.

The request to projects is concrete: if your CI allows it, build and test against JDK 28 twice — previews off, which is the default and should behave exactly as before, and previews on. Changes that follow from value semantics or the record rules are yours to adapt to; anything else is a JDK bug to report to the valhalla-dev mailing list.

None of this should surprise code that respected the "value-based class" rules: JDK 8 introduced that concept for Optional and java.time, its description was later refined to mention synchronization explicitly, and JDK 16 extended it to the primitive wrappers. The heads-up is the moment those warnings start to bite.

Source: Inside Java, "Quality Outreach Heads-up - JDK 28: Value Classes" — https://inside.java/2026/10/27/quality-heads-up