chaokunyang

Apache Fory achieved 2.78×–12.12× the throughput of kotlinx.serialization, Moshi with generated adapters, and Jackson Kotlin across the measured serialization and deserialization operations

fory json source code: https://github.com/apache/fory/blob/main/java/fory-json/READ...

Apache Fory JSON is a high-performance JSON serialization framework for Java. It maps Java objects to and from standard JSON text and UTF-8 bytes.

In the published benchmarks, it reaches up to 10.91× Jackson’s throughput and 10.89× Gson’s in java-json-benchmark, and up to 5.55× and 10.00× respectively in the jvm-serializers MediaContent benchmark.

It supports JDK 8+, Android, and GraalVM Native Image. JDK17+ Record is also supported.

Feedback is welcome.

Apache Fory 1.2.0 is out.

The main Java change is JDK 25 support without using sun.misc.Unsafe in the active runtime path. Older JDKs keep the existing fast path, while JDK 25+ uses replacement implementations based on supported JVM APIs.

Other notable changes:

- Java 9/16 module-info generation

- JDK 26+ final field deserialization support even when --illegal-final-field-mutation=deny

- compatible scalar field reads for schema evolution, e.g. int64 <-> String when the conversion is lossless

- generated gRPC service companions across Java, Rust, Go, Kotlin, Scala, C#, Python, and JavaScript/TypeScript - compatible-mode and row-format performance work

Feedback from people testing serialization libraries on newer JDKs or dealing with Unsafe removal would be useful.

1. 10X faster serialization than protobuf c++ 2. Shared/Circular reference tracking Support 3. Polymorphism and tagged union support 4. Schema evolution support 5. idiomatic domain object API

Flatbuffer Example:

namespace demo;

table Node {

  parent: Node (fory_weak_ref: true);

  children: [Node] (fory_ref: true);

  cached: Node (fory_ref: true, fory_thread_safe_pointer: false);

}

Protobuf Example:

syntax = "proto3";

message TreeNode {

  TreeNode parent = 1 [(fory).weak_ref = true];

  repeated TreeNode children = 2 [(fory).ref = true];

}

If you already have .proto or .fbs schemas and you want shared/circular reference support, with the Fory compiler you can keep those schemas, add a small set of Fory options, then foryc generates idiomatic native models across Fory-supported languages

With fory first-class object graph serialziation support, you can serialize object graphs without manual *_id link reconstruction or rewriting your entire schema into Fory Schema.

1. GitHub: https://github.com/apache/fory

2. Compiler docs: https://fory.apache.org/docs/compiler

Tiny Schema demo

message Customer { string id = 1; string name = 2; }

message Order {

  string order_id = 1;

  ref Customer customer = 2;

  list<string> items = 3;

}

1. Docs https://fory.apache.org/docs/compiler

2. GitHub https://github.com/apache/fory

3. Benchmarks https://github.com/apache/fory/tree/main/docs/benchmarks

Fory C++ serialization blog: https://fory.apache.org/blog/fory_cpp_blazing_fast_serializa...

This project is for running local CLI/agent loops on macOS/Linux/Windows while executing commands inside browser-hosted terminals for cloud servers. The key goal is output/exit-code parity so local automation can trust remote runs.

GitHub Repo: https://github.com/inclusionAI/asystem-awex

Awex is a weight synchronization framework between training and inference engines designed for ultimate performance, solving the core challenge of synchronizing training weight parameters to inference models in the RL workflow. It can exchange TB-scale large-scale parameter within seconds, significantly reducing RL model training latency. Main features include: Blazing synchronization performance: Full synchronization of trillion-parameter models across thousand-GPU clusters within 6 seconds, industry-leading performance; Unified model adaptation layer: Automatically handles differences in parallelism strategies between training and inference engines and tensor format/layout differences, compatible with multiple model architectures; Zero-redundancy Resharding transmission and in-place updates: Only transfers necessary shards, updates inference-side memory in place, avoiding reallocation and copy overhead; Multi-mode transmission support: Supports multiple transmission modes including NCCL, RDMA, and shared memory, fully leveraging NVLink/NVSwitch/RDMA bandwidth and reducing long-tail latency; Heterogeneous deployment compatibility: Adapts to co-located/separated modes, supports both synchronous and asynchronous RL algorithm training scenarios, with RDMA transmission mode supporting dynamic scaling of inference instances; Flexible pluggable architecture: Supports customized weight sharing and layout behavior for different models, while supporting integration of new training and inference engines. GitHub Repo: https://github.com/inclusionAI/asystem-awex

I also did a benchmark with dill, it shows that: fory is 20~40X faster and up to 7x higher compression ratio compared to dill. I don't dive into dill to see how it works. Here is my benchmark code:

https://github.com/chaokunyang/python_benchmarks

Yes, you are right. I missed this when I wrote the benchmark code. I will update the benchmark code and share the results here

I understand your concern. Personally, I’m open to using AI as part of the development process, but the majority of the code in this repository has been written manually and carefully reviewed.

The AGENTS.md file was added only recently. Its original purpose wasn’t to hand code generation entirely to an AI, but rather to use AI as a pair‑programming debugger — for example, having it walk through tricky binary parsing issues byte‑by‑byte. Serialization in a compact binary format can be hard to debug, and AI can sometimes save hours by quickly pinpointing structural mismatches.

That said, serialization is a fundamental piece of infrastructure, so we remain conservative: any AI‑assisted changes go through the same rigorous review and test process as everything else. As technology evolves, I think it’s worth exploring new tools — but with care.

You mean this file? https://github.com/apache/fory/blob/main/AGENTS.md

I liked the name “Fury” too — I actually named it myself and was really fond of it, but unfortunately we had to change it.

DOP is great, but there’s always a gap between DOP and OOP. That gap is where Fory comes in. Right now, Fory takes an OOP‑first approach, but next we’ll add a DOP path by introducing an optional IDL — bridging the two styles. My goal is for the IDL to also support optional OOP‑style expressiveness, so teams can choose the balance that fits their needs.

DOP is great for certain scenarios, but there’s always a gap between DOP and OOP. That gap is where an extra domain model and the conversion step come in — especially in systems that rely heavily on polymorphism or want to keep serialization types decoupled from core business models.

The Rust benchmarks in Fory are intended more as end‑to‑end benchmarks for typical OOP‑style application scenarios, not just raw buffer write speed.

Protobuf is very much a DOP (data‑oriented programming) approach — which is great for some systems. But in many complex applications, especially those using polymorphism, teams don’t want to couple Protobuf‑generated message structs directly into their domain models. Generated types are harder to extend, and if you embed them everywhere (fields, parameters, return types), switching to another serialization framework later becomes almost impossible without touching huge parts of the codebase.

In large systems, it’s common to define independent domain model structs used throughout the codebase, and only convert to/from the Protobuf messages at the serialization boundary. That conversion step is exactly what’s represented in our benchmarks — because it’s what happens in many real deployments.

There’s also the type‑system gap: for example, if your Rust struct has a Box<dyn Trait> field, representing that cleanly in Protobuf is tricky. You might fall back to a oneof, but that essentially generates an enum variant, which often isn’t what users actually want for polymorphic behavior.

So, yes — we include the conversion in our measurements intentionally, to reflect the real‑world large systems practices.

DOP is very interesting, I like this idea too — most DOP approaches are implemented via an IDL, which is another valid direction. I plan to support that in Fory. I want to give users the freedom to choose the model that works best for them.

Binary XML encoding (like W3C EXI) is useful in some contexts, but it’s generally not as efficient as modern binary serialization formats. It also can’t naturally express shared or circular reference semantics, which are important for complex object graphs.

Fory’s format was designed from the ground up to handle those cases efficiently, while still enabling cross‑language compatibility and schema evolution.

Apache Arrow is more of a memory format than a general‑purpose data serialization system. It’s great for in‑memory analytics and GPU‑friendly columnar storage.

Apache Fory, on the other hand, has its own wire‑stream format designed for sending data across processes or networks. Most of the code is focused on efficiently converting in‑memory objects into that stream format (and back) — with features like cross‑language support, circular reference handling, and schema evolution.

Fory also has a row format, which is a memory format, and can complement or compete with Arrow’s columnar format depending on the use case.

In our Java benchmarks, Fory is actually faster than FlatBuffers — you can try it yourself here: https://github.com/apache/fory/blob/main/java/benchmark/src/...

We haven’t tested FlatBuffers vs. Fory for Rust yet, but we plan to.

It’s also worth noting the focus is a bit different: FlatBuffers is great for certain constrained scenarios (e.g., games, embedded), while Fory is a more general‑purpose serialization framework with features like cross‑language object graph support, circular reference handling, and schema evolution.

JS support is still experimental, I have not publish it to npm

The https://github.com/apache/fory/blob/main/AGENTS.md is a very detailed document only for AI coding, but an excelent reference for development. But you are right, it may introduce concerns, let me remove it from landing pages

should be ok now

Fory also compress integers using varint or zigzag encoding. The size are basically same:

| data type | data size | fory | protobuf |

| --------------- | --------- | ------- | -------- |

| simple-struct | small | 21 | 19 |

| simple-struct | medium | 70 | 66 |

| simple-struct | large | 220 | 216 |

| simple-list | small | 36 | 16 |

| simple-list | medium | 802 | 543 |

| simple-list | large | 14512 | 12876 |

| simple-map | small | 33 | 36 |

| simple-map | medium | 795 | 1182 |

| simple-map | large | 17893 | 21746 |

| person | small | 122 | 118 |

| person | medium | 873 | 948 |

| person | large | 7531 | 7865 |

| company | small | 191 | 182 |

| company | medium | 9118 | 9950 |

| company | large | 748105 | 782485 |

| e-commerce-data | small | 750 | 737 |

| e-commerce-data | medium | 53275 | 58025 |

| e-commerce-data | large | 1079358 | 1166878 |

| system-data | small | 311 | 315 |

| system-data | medium | 24301 | 26161 |

| system-data | large | 450031 | 479988 |