Gson 2.14.0 favors compatibility over new features
The current Maven Central release is Gson 2.14.0, a Java library for turning objects into JSON and reading JSON back into typed objects. It also has a JSON tree API and streaming readers and writers. The README says the project is in maintenance mode: maintainers expect to fix existing bugs, while large new features are unlikely. That makes Gson easier to judge. Pick it for a stable, familiar job, rather than for an expanding serialization platform.
Our commit 15ca736 checkout was 2.3 MB with 313 files and about 56,997 source lines. Much of that source supports compatibility, adapters, documentation, and integration checks around a compact public task. Version 2.14.0 added adapters for java.time classes without opening their private fields on recent JDKs. It also tightened integer parsing and duplicate-key handling, showing that maintenance still includes behavior changes worth reading before an upgrade.
Reflection handles classes you cannot annotate
Gson's most useful trait is its ability to work with existing Java classes, including classes whose source you cannot change. toJson() and fromJson() cover common cases, while GsonBuilder controls naming, exclusions, null output, and registered adapters. Generic collections need a TypeToken because Java erases their type arguments at runtime. The user guide explains that a Gson instance keeps no operation state, so applications can reuse it instead of constructing one for each conversion.
The 313-file repository includes direct tests for collections, maps, records, reflection filters, SQL types, streaming, generic resolution, and security cases. That breadth matters because reflection can create surprising results around constructors, field visibility, and runtime types. For formats you control, explicit TypeAdapter or TypeAdapterFactory code makes the contract easier to see. For third-party classes, ReflectionAccessFilter can stop accidental access to platform internals.
What happened when we ran it
Our sandbox installed the commit in 40 seconds and completed the build in 75 seconds. We used an unprivileged container with 3 CPUs, 10 GB of RAM, and JDK 21. The build result matters because the source enforces formatting and compiler checks across a multi-module Maven project. The repository also carried 6 CI workflows and no Dockerfile, which is reasonable for a library consumed from Maven Central.
The test command failed with exit code 1 after 12 seconds. Maven Surefire recorded 16,892 passed, 0 failed, and 64 skipped out of 16,956. After those outcomes, the log marked Test: Java Platform Module System (JPMS) as FAILURE; the GraalVM native-image and code-shrinking modules were skipped. The supplied final lines contain no exception or cause for the JPMS result, so we cannot say whether the fault was code, configuration, or the container.
Java 8 users consume it; JDK 17 builds it
Gson 2.14.0 supports Java 8 at runtime, and the published artifact declares the JPMS name com.google.gson. The source build requires JDK 17 through 25, with JDK 21 recommended in the README. Its module descriptor makes java.sql optional for SQL date and time adapters. It also treats jdk.unsupported as optional because Gson can use sun.misc.Unsafe to construct classes without no-argument constructors.
Our 75-second build used the recommended JDK 21 image, yet the later 12-second test step still stopped at the JPMS module. That is a release-gate concern for teams that ship named modules. A classpath-only Java 8 service has a different risk profile, but it should still test its own adapters and serialized fixtures. JSON compatibility belongs to the application contract, especially when a library update tightens previously accepted input.
Android and Kotlin should start elsewhere
The README directly says Gson is not recommended for Android because its open-ended reflection interacts poorly with shrinking, optimization, and obfuscation. The troubleshooting guide documents R8 rules and ways to block reflection, but it still warns that many features can fail in a minified environment. Gson also lacks explicit handling for Kotlin non-null types and constructors with default arguments. Those are ordinary language features, so their absence is enough to choose a Kotlin-aware library at the start.
Our 3-CPU, 10 GB sandbox tested a JVM build; it did not build an Android APK, run R8, or exercise Kotlin and Scala models. The Android and language warnings therefore come from Gson's maintainers, not from an invented lab result. Moshi offers Kotlin adapters and code generation, while kotlinx.serialization uses compiler-generated serializers across Kotlin targets. Both line up better with the constraints Gson itself names.
Maintenance mode leaves old feature requests open
Issue #1102 has asked for java.util.Optional support since 2017, and issue #1443 has requested JSON Pointer support since 2018. Issue #1180 asks for a way to disable JsonReader buffering or recover its exact read position when JSON is embedded in a larger stream. These are concrete gaps, rather than evidence that basic object mapping is neglected. They show why a team should compare required APIs before accepting Gson's small surface as a benefit.
GitHub recorded a last push on September 13, 2026, and listed 337 combined issues and pull requests. Issue #3047, updated the day before, reports that a JSON null inside AtomicIntegerArray escapes as IllegalStateException instead of JsonSyntaxException. Active discussion and 6 CI workflows support the picture of maintained code, while the 12-second lab test still ended in a JPMS failure. Gson is mature enough to be conservative, and conservative enough that missing features may stay missing.