fastjson2: Alibaba's Java JSON library, and the AutoType problem that shaped it

Adding the dependency and parsing on the first line

The quick start is a Maven dependency and a static import. The groupId changed from the 1.x line, which is the first thing that trips up an upgrade:

<dependency>
    <groupId>com.alibaba.fastjson2</groupId>
    <artifactId>fastjson2</artifactId>
    <version>2.0.65</version>
</dependency>

With Gradle the same coordinate reads as one line:

dependencies {
    implementation 'com.alibaba.fastjson2:fastjson2:2.0.65'
}

The whole API is reachable through the `JSON` facade, and the README's example is short enough to be the entire mental model:

import com.alibaba.fastjson2.JSON;

// Parse
User user = JSON.parseObject("{\"name\":\"John\",\"age\":25}", User.class);

// Serialize
String json = JSON.toJSONString(user);

Parse with `parseObject`, serialize with `toJSONString`. The same facade also gives you `JSONObject` and `JSONArray` for the untyped case, and bean serialization is configured through annotations, a global naming strategy, or per-call features.

The README targets JDK 8, 11, 17 and 21, and claims compact string, Record and Vector API support, so a JDK 8 service and a JDK 21 service can share a dependency version. Kotlin projects take a separate `fastjson2-kotlin` module with an idiomatic DSL, and the README notes that the reflection library is needed for data classes and constructor-based parameter passing.

JSONB, JSONPath and JSON Schema beyond parse and print

The features that separate fastjson2 from a basic object mapper are the extras in the advanced section of the README.

JSONB is the binary counterpart to JSON text, documented on its own page, and the library reads and writes both without a separate API. That matters for internal protocols and big-data pipelines where parsing cost dominates, and it is the reason the topic list includes `jsonb`.

JSONPath is supported and described as SQL:2016 compatible, so you can extract one field out of a large document without materializing the rest. The repository tree shows `core/` holding the main implementation and `docs/` the documentation sources, with `codegen/` for generated sources.

JSON Schema validation is built in, which is a differentiator. Most Java JSON libraries leave validation to a separate library such as a networknt schema validator, so having it in the same dependency means a parse and a validation pass share one traversal.

The library also targets Android 8 and up, and the repository carries dedicated Android test modules and separate Android release variants, so this is not only a server-side library. GraalVM Native Image compatibility is listed as a highlight, and the topics confirm it with `graal` and `graalvm-native-image`.

Spring integration is modular rather than assumed: the tree has `extension-spring5/`, `extension-spring6/`, `extension-jaxrs/` and `extension-solon/`, with matching example test modules, so a Spring application picks the extension matching its generation.

AutoType is off by default, and that is the whole security story

fastjson's reputation comes from AutoType, the feature that lets JSON name the class it should be deserialized into. It is also the source of a long line of remote code execution issues in the 1.x line, and reading fastjson2's recent releases is largely reading the story of that feature being locked down.

The design position is stated in the highlights: AutoType disabled by default, no hardcoded whitelist, SafeMode support. That is a direct contrast with 1.x, where a global parser configuration could be turned on in one place and affect every parse in the process.

The 2.0.63 release on 2026-07-29 hardened the allowlist. Type names containing URL-special characters are now rejected before reaching the class loader, the accept name text is verified after a whitelist hash match so a collision alone cannot authorise a type, and an accept prefix no longer covers the `ClassLoader`, `DataSource` and `RowSet` gadget base types unless the entry names the type in full. The same release limited the number of digits accepted for numeric literals to stop a `BigInteger` quadratic blow-up on crafted long input, and documented `-Dfastjson2.parser.safeMode=true` as a mitigation for anyone who could not upgrade right away.

The 2.0.65 release on 2026-09-02 fixed an authorization bypass reachable when `JSONReader.Feature.SupportAutoType` is enabled: a cache hit on the FNV-1a-64 hash of `@type` is no longer treated as proof that the type was authorised. It also restored `fastjson2-extension-spring6` to Maven Central, where it had been missing for 2.0.62 through 2.0.64 because those releases were built with a JDK that did not activate the `enable-for-17+` profile, so the module never entered the build reactor.

The practical reading is straightforward. If you do not need polymorphic deserialization, do not enable AutoType. If you do, treat it as an attack surface and pin to a current patch version.

Migrating from fastjson 1.x through a compatibility module

For an existing codebase, the fastjson2 tree carries a `fastjson1-compatible/` module that lets you change coordinates without rewriting calls first. It ships under the old groupId:

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>2.0.65</version>
</dependency>

That swap pulls the compatibility implementation in place of the 1.x library, so imports like `com.alibaba.fastjson.JSON` keep resolving while the implementation underneath is fastjson2's.

The README is careful about the limits, saying that 100% compatibility is not guaranteed and asking you to test thoroughly and report issues. The 2.0.64 release notes show why that caution is reasonable, since several of that release's fixes were in the compatibility layer itself: `serialVersionUID` added to `JSONArray` for Java serialization, JSONPath consecutive writes failing in the 1.x path, and `ParserConfig.propertyNamingStrategy` added for the 1.x naming behaviour.

The same release fixed things in the core as well, including a `strBuf` that was not kept in sync after mid-loop growth and could produce corrupted output, a `MethodHandles.Lookup` initialization order bug, and the global naming strategy not being applied to Java records.

A sensible migration is therefore staged: swap to the compatibility artifact, run the full test suite with AutoType still off, then decide per service whether the native fastjson2 API is worth the churn. The Kotlin module is a separate decision again, since the extension DSL is a different surface rather than a compat shim.

How this compares with Jackson and Gson

The README's performance claim is direct: fastjson2 significantly outperforms Jackson, Gson and `org.json`, with a benchmark link to a wiki page. It does not put numbers in the README itself, and the benchmark module in the tree is named `benchmark/` and `benchmark_25/`, so the comparison lives outside the documentation you read first.

The more durable differences are structural.

Jackson is the reference implementation for data binding in the JVM ecosystem, with deep Spring integration and the largest body of Stack Overflow answers. Its cost is configuration surface and annotation vocabulary, and its stream-based API is a bigger rewrite than a static facade.

Gson is the smallest of the three and stays out of the way, but it has no binary format, no JSONPath and no schema validation, so those all come as extra dependencies.

fastjson2's distinctive combination is that JSONB, JSONPath, JSON Schema and AutoType-style type hints all arrive in one artifact, which is attractive when you are parsing heterogeneous payloads from many upstream systems. The offsetting cost is that AutoType exists at all, and that its history is a recurring source of security releases.

For a team that only needs clean bean mapping and already has Jackson on the classpath, the argument for switching is thin. For a pipeline reading large binary documents or validating against a schema at the edge, the extra features are the reason to look.

Repository layout, build tooling and where the README cuts off

The repository is a Maven multi-module build with a wrapper committed, `mvnw` and `mvnw.cmd`, so building does not require a local Maven install. Alongside `pom.xml` there are `test-jdk17/` and `test-jdk25/` modules, which is how the project checks that the same code still compiles and passes on newer JDKs than the 8 baseline it claims.

There is also `safemode-test/`, a dedicated module for the SafeMode mitigation path, which tells you the security mode is treated as a tested configuration rather than a documented afterthought. CI runs through GitHub Actions on the `main` branch, with a Codecov badge for coverage.

The README is bilingual, with `README_cn.md` beside it, and the visible portion covers installation for the core library, the 1.x compatibility module and the Kotlin module. It is cut off partway through the Spring integration section, so the framework wiring details are in `docs/` rather than in the file most people read first.

Licensing is Apache-2.0, and there is a `SECURITY.md` alongside `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and an `AGENTS.md`, which is a reasonable sign for a library that has handled disclosure well enough to publish coordinated fixes in release notes.

The last push to the repository was on 2026-09-17, two weeks after the 2.0.65 security release, and the release cadence through 2026 has been roughly monthly with patch releases in between.

Editorial conclusion

fastjson2 is a good fit when you want a drop-in JSON layer on Java 8 through 21 with a binary format, and a poor fit when you want a JSON library whose security posture has been quiet for a year. The three releases on this branch are all security or bugfix releases, and the AutoType subsystem is the reason. Two decisions matter more than any benchmark: leave `SupportAutoType` off unless you genuinely need polymorphic deserialization, and if you cannot upgrade immediately, the project documents `-Dfastjson2.parser.safeMode=true` as a mitigation. For a migration from fastjson 1.x, the compatibility module under groupId `com.alibaba` saves real work, but the README states plainly that full compatibility is not guaranteed. Compare the API surface against Jackson before switching, and check whether your build has the `enable-for-17+` profile active, since its absence is why one module vanished from Maven Central for three releases.

Frequently asked questions

Official sources

1. alibaba/fastjson2 on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases