Add type adapters for `java.time` classes #2948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merged

eamonnmcmanus merged 27 commits into google:main from eamonnmcmanus:javatime

Dec 23, 2025

+818 −75

Member

eamonnmcmanus commented Nov 25, 2025 •

edited

Loading

Add type adapters for java.time classes.

These adapters essentially freeze the JSON representation thatReflectiveTypeAdapterFactory established by default, based on the private fields of java.time classes. That's not a great representation, but it is understandable. Changing it to anything else would break compatibility with systems that are expecting the current format.

If Gson had been updated with java.time adapters at the time the java.time API was added, the representation would surely have been something else, probably ISO standard formats. We can potentially supply non-default adapters for that, but we'll still need to have these legacy adapters by default.

I've been meaning to make this change for a while, but the need to do so becomes more urgent with this JDK
commit which makes a number of java.time fields transient. That means that, in JDK 26, the reflective-based adapter will no longer work with the classes that were changed.

This addresses #1059 and #739. All relevant classes in the java.time package are covered.

(Google internal bug reference: b/463237567.)

eamonnmcmanus added 6 commits

November 24, 2025 16:18


          Add type adapters for java.time classes.

9e7b302

These adapters essentially freeze the JSON representation that
`ReflectiveTypeAdapterFactory` established by default, based on the
private fields of `java.time` classes. That's not a great
representation, but it is understandable. Changing it to anything else
would break compatibility with systems that are expecting the current
format.

If Gson had been updated with `java.time` adapters at the time the
`java.time` API was added, the representation would surely have been
something else, probably ISO standard formats. We can still supply
non-default adapters for that, but we'll still need to have these legacy
adapters by default.

I've been meaning to make this change for a while, but the need to do so
becomes more urgent with [this JDK
commit](openjdk/jdk@cc05530)
which makes a number of `java.time` fields `transient`. That means that
the reflective-based adapter will no longer work with the classes that
were changed.


          Apply a couple of Error Prone suggestions.

28393e1


          Reformat a couple of source files.

9b12b2e


          Fix another EP warning.

3a38f77


          Fix a particularly annoying EP warning/error.

9b48171


          Update the Android API level.

f20ca75

I think it is time to do this, but obviously it should be a separate PR.

eamonnmcmanus requested a review from cpovirk

November 25, 2025 01:54

cpovirk reviewed

View reviewed changes

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated

    
                      }

                      @Override

                      @SuppressWarnings("JavaDurationGetSecondsGetNano")

Member

cpovirk Nov 25, 2025

Huh, I would have hoped that the getSeconds and getNano calls below were close enough to avoid this warning :(

Member Author

eamonnmcmanus Dec 18, 2025

I'm not sure what you mean? The warning is supposed to prevent you from calling getSeconds() when you meant toSeconds().

Member

cpovirk Dec 19, 2025

https://errorprone.info/bugpattern/JavaDurationGetSecondsGetNano:

If you call duration.getNano(), you must also call duration.getSeconds() in ‘nearby’ code.

I get the impression that the check would be happy with foo(duration.getSeconds(), duration.getNano()) but not the array case. But I see no other examples in my depot search for ([{]|new.*\[)[^\042]*getSeconds.*getNano lang:java, so I don't think I'll bother to file a feature request.

(I forget where we landed with getSeconds vs. toSeconds. I just know that I got sad about the various get* and to* methods, including the to*Part methods, in b/201676318.)

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

pom.xml Outdated Show resolved Hide resolved

cpovirk mentioned this pull request

Change the minimum supported Android API to 26. #2949

Closed

Marcono1234 reviewed

View reviewed changes

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/test/java/com/google/gson/functional/DefaultTypeAdaptersTest.java Show resolved Hide resolved

gson/src/test/java/com/google/gson/functional/DefaultTypeAdaptersTest.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

eamonnmcmanus and others added 9 commits

December 18, 2025 16:09


          Substantial rework.

4ab05a9

* Move the new `TypeAdapter` implementations into a new class
  `JavaTimeTypeAdapters`. This allows us to omit that class from Android
  builds where it otherwise triggers warnings about SDK levels.

* Ensure that every `java.time` class that needs a `TypeAdapter` has
  one. This doesn't include "subpackages" `java.time.*` like
  `java.time.chrono`, where it doesn't appear that there are any classes
  that are likely to be serialized to JSON.

* Fix the handling of `ZoneId` and its subclasses.


          refactor: slightly optimize ConstructorConstructor (google#2950)

788fd4a

* refactor: slightly optimize ConstructorConstructor

* Update comments

Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>

* spotless apply

Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>

---------

Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>


          Fix outdated comment (google#2954)

4ddb1e5


          Compilation fixes.

6e13db7

I copied the internal version that was running on Google's
infrastructure, and some adjustments were needed.


          Merge branch 'main' into javatime

16955d4


          Fix lint errors.

5b36906


          Fix a particularly annoying lint error.

4d0e6fe


          Fix the fix.

6ab3eda


          Further fixes.

6146d57

This still doesn't pass with a local build, and I may need to debug an
OSGi problem.

cpovirk approved these changes

View reviewed changes

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated

    
                      }

                      @Override

                      @SuppressWarnings("JavaDurationGetSecondsGetNano")

Member

cpovirk Dec 19, 2025

https://errorprone.info/bugpattern/JavaDurationGetSecondsGetNano:

If you call duration.getNano(), you must also call duration.getSeconds() in ‘nearby’ code.

I get the impression that the check would be happy with foo(duration.getSeconds(), duration.getNano()) but not the array case. But I see no other examples in my depot search for ([{]|new.*\[)[^\042]*getSeconds.*getNano lang:java, so I don't think I'll bother to file a feature request.

(I forget where we landed with getSeconds vs. toSeconds. I just know that I got sad about the various get* and to* methods, including the to*Part methods, in b/201676318.)

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Outdated Show resolved Hide resolved

gson/src/main/java/com/google/gson/internal/bind/TypeAdapters.java Show resolved Hide resolved

gson/src/test/java/com/google/gson/functional/DefaultTypeAdaptersTest.java Show resolved Hide resolved

nithril-png mentioned this pull request

v3.3.9 still has serialization problems argoproj/argo-workflows#9692

Open

eamonnmcmanus added 9 commits

December 23, 2025 12:21


          Revert to Android API 23, but with gummy-bears-api.

be7e42a


          Annotate JavaTimeTypeAdapters to suppress animal-sniffer errors.

fa66bb9


          Update OSGiManifestIT not to depend on order.

c67e4fe

It appears that sometimes the clauses being checked for appear in the
other order, possibly because of a `HashMap` or the like somewhere in
the guts of OSGi. I haven't seen this on GitHub, but I do see it when
running locally with Google's JDK, which has more hash randomization.


          Fix use of assignment expression.

957cfbe


          Remove the parser, which was overkill.

e1cee31

It's enough just to swap the two clauses of a line when they are not in
the expected order.

Also, unrelatedly, update `protobuf-maven-plugin`.


          Merge branch 'osgimakingworkforpeopleagain' into javatime

41b7490


          Use a local @IgnoreJRERequirement.

f36a5c5


          Configure the local animal-sniffer annotation.

e752f74


          Suppress IdentifierName warning.

0ba4b48

eamonnmcmanus added 3 commits

December 23, 2025 14:10


          Update comments and undo an unnecessary split.

3d58365


          Merge branch 'osgimakingworkforpeopleagain' into javatime

8ac01db


          Restore Math.toIntExact.

dfa4883

eamonnmcmanus merged commit c47db7b into google:main

14 of 15 checks passed

eamonnmcmanus deleted the javatime branch

December 23, 2025 22:38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet