JDK-8367031 : [backout] Change java.time month/day field types to 'byte'
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 25
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-09-06
  • Updated: 2025-09-22
  • Resolved: 2025-09-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25 JDK 26
25.0.2Fixed 26 b16Fixed
Related Reports
Causes :  
JDK-8334742 - Change java.time month/day field types to 'byte'
Sub Tasks
JDK-8367032 :  
Release Note: Regression in Serialization of LocalDate Class Objects - Resolved
JDK-8368106 :  
Release Note: Resolved Regression in java.time Class Objects - Open
Description
The serialized form of several `java.time` class objects is incompatible between JDK 25 and previous releases due to a change in the type of the month and day fields.

The serialized form of LocalDate instances is not affected; the serialized form uses an externalized form in which the stream format is independent of the field types.

The purpose of the change was to enable packing fields more tightly in anticipation of converting to value classes in the Valhalla project.
The changed field types result in the serialized form of the classes being incompatible between JDK 25 and previous versions. The change was made in JDK-8334742. The affected class are LocalDate, YearMonth, MonthDay, and HirjahDate.
When de-serializing, an exception is thrown:

`java.io.InvalidClassException: java.time.LocalDate; incompatible types for field day
	at java.base/java.io.ObjectStreamClass.matchFields(ObjectStreamClass.java:2077)
`
Comments
[jdk25u-critical-request] Approval Request from Roger Riggs The change in JDK-8334742 caused a regression in serialization of java.time class objects. The backout has been applied to the mainline and should be propagated to JDK 25.0.1. The backout is low risk; it directly restores the previous code and behavior.
19-09-2025
[jdk25u-fix-request] Approval Request from Roger Riggs The change in JDK-8334742 caused a regression in serialization of java.time class objects. The backout has been applied to the mainline and should be propagated to jdk25u.
18-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u/pull/217 Date: 2025-09-18 21:40:22 +0000
18-09-2025
A pull request was submitted for review. Branch: jdk25 URL: https://git.openjdk.org/jdk/pull/27375 Date: 2025-09-18 21:25:13 +0000
18-09-2025
Since this is a clean backout, I think it makes sense to backport it to 25u pretty soon, so it definitely hits 25.0.2.
18-09-2025
Changeset: 0756ecb2 Branch: master Author: Roger Riggs <rriggs@openjdk.org> Date: 2025-09-17 19:49:22 +0000 URL: https://git.openjdk.org/jdk/commit/0756ecb214b8ab76cb69f354063d153b72f978c2
17-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27346 Date: 2025-09-17 13:39:18 +0000
17-09-2025
The issue is about serializating LocalDate.class (and 3 other java.time classes), not LocalDate objects. So while it is a regression impacting JDK 21/25 interop, it looks like it may be limited to RMI like reflection frameworks that serialize classes and their meta data. An application or library that just persists a LocalDate object should not be impacted (can serialize a LocalDate on JDK 21 and de-serialize with JDK 25). I've ran the latest JCK 25 build and there aren't any failures. It may be that we have a blind spot in our testing of class objects and this is something we need to examine. As Roger notes, backing out the change would be low-risk. At the same time, JDK 25 GA is <10 day away and this would rquire a re-spin and be disruptive. It would be simpler to just defer this to 25u. JDK 25.0.1 is Oct so only a few weeks after GA. The issue can be documented in a "known issue" release note.
07-09-2025
The PR of the original change is: https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624 It changed 4 classes in java.time: java.time.YearMonth java.time.MonthDay java.time.LocalDate java.time.chono.HijrahDate No tests were changed. It would be advisable to add a test of the serialization of those types between JDK 21 (for example) and JDK 25 to confirm the problem no long exists.
07-09-2025