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
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.
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.
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:
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.
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.
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.