Download Latest Version v1.3.0 source code.zip (7.5 MB)
Email in envelope

Get an email when there's a new version of Fury

Home / v1.2.0
Name Modified Size InfoDownloads / Week
Parent folder
README.md 2026-06-13 11.8 kB
0
v1.2.0 source code.tar.gz 2026-06-13 5.7 MB
1 1 weekly downloads
v1.2.0 source code.zip 2026-06-13 7.4 MB
0
Totals: 3 Items   13.2 MB 1

Highlights

  • Expanded generated gRPC support across Go, Rust, Kotlin, Scala, C#, and JavaScript, including Node.js and browser gRPC-Web support for JavaScript.
  • Improved cross-language compatibility with refined register-by-name APIs, compatible scalar read conversions, and default compatible mode for native serialization.
  • Strengthened Java platform support by adding Java 9/16 module-info generation and removing sun.misc.Unsafe usage for JDK 25.
  • Improved runtime safety and robustness with additional read checks, deflater leak fixes, and safer serializer/type-info error handling.
  • Optimized compatible-mode and row-format performance through faster compatible reads, compact row layout caching, and inlined custom-codec dispatch.
  • Enhanced compiler output quality across Rust, C++, and service generation with better identifier escaping, name-collision handling, nested container reference handling, and map code generation.

Java 25+ Without sun.misc.Unsafe

JDK 25 continues the platform shift away from sun.misc.Unsafe. Fory 1.2.0 adds a Java 25 multi-release runtime path so applications can run on JDK 25+ without resolving sun.misc.Unsafe from Fory's active class graph.

Older JDKs keep the existing fast paths. On JDK 25+, Fory uses replacement classes backed by supported JVM mechanisms such as VarHandle, MethodHandle, arrays, and ByteBuffer. Classes that previously depended on constructor bypassing should provide an accessible no-arg constructor, use records, or register a custom serializer.

Compatible Scalar Field Reads

Compatible mode already allows readers and writers to add, remove, and reorder fields. Fory 1.2.0 extends that model to selected scalar type changes: when a matched top-level field changes between boolean, string, numeric, and decimal types, the reader can deserialize the value if the conversion is lossless.

Examples include reading "123" as an integer field, reading 1 or 0 as a boolean field, reading booleans as 1/0, reading numbers or decimals as canonical strings, and widening or narrowing numeric values only when no range or precision is lost. Invalid strings, out-of-range values, lossy float/integer conversions, and reference-tracked scalar type changes fail during deserialization. The conversion applies to matched compatible fields, not to root values or collection elements.

The examples below show Rust and Java using an int64 writer field and a String reader field. The same compatible scalar field conversion is supported across Fory's compatible-mode runtimes: Java, Python, Rust, C++, Go, C#, Swift, Dart, JavaScript/TypeScript, Kotlin, and Scala. Compatible mode is enabled by default in the Java and Python runtimes for both xlang and native serialization.

Rust example:

:::rust
use fory::{Fory, ForyStruct};

#[derive(ForyStruct)]
struct MetricV1 {
    value: i64,
}

#[derive(ForyStruct)]
struct MetricV2 {
    value: String,
}

let mut writer = Fory::builder().xlang(true).compatible(true).build();
writer.register_by_name::<MetricV1>("example.Metric")?;

let mut reader = Fory::builder().xlang(true).compatible(true).build();
reader.register_by_name::<MetricV2>("example.Metric")?;

let bytes = writer.serialize(&MetricV1 { value: 42 })?;
let value: MetricV2 = reader.deserialize(&bytes)?;
assert_eq!(value.value, "42");

Java example:

:::java
public class MetricV1 {
  public long value;
}

public class MetricV2 {
  public String value;
}

Fory writer = Fory.builder().withXlang(true).withCompatible(true).build();
writer.register(MetricV1.class, "example", "Metric");

Fory reader = Fory.builder().withXlang(true).withCompatible(true).build();
reader.register(MetricV2.class, "example", "Metric");

MetricV1 source = new MetricV1();
source.value = 42L;
byte[] bytes = writer.serialize(source);
MetricV2 value = reader.deserialize(bytes, MetricV2.class);
assert value.value.equals("42");

The same rule works in the other direction, for example reading a String field value such as "42" as int64, when the string uses Fory's strict finite decimal grammar and the target range can represent the value exactly.

Generated gRPC Support

Fory 1.2.0 expands compiler-generated gRPC service companions. The generated services use standard gRPC transports, channels, deadlines, metadata, interceptors, status codes, and streaming shapes, while request and response objects are encoded with Fory instead of protobuf message bytes. Use this mode when both sides of the RPC are generated from the same Fory IDL, protobuf IDL, or FlatBuffers IDL and you want gRPC operational semantics with Fory payload encoding.

Generated gRPC support now covers Java, Python, Go, Rust, C#, Scala, Kotlin, and JavaScript/TypeScript. JavaScript includes Node.js gRPC support and browser gRPC-Web client generation. Only Rust and Java snippets are shown below; the other supported languages provide the same Fory-backed service companion model without duplicating code here.

The examples below use this shared schema:

:::protobuf
package demo.greeter;

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string reply = 1;
}

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

Rust generation emits tonic-based service API and binding modules:

:::rust
use demo_greeter::{HelloReply, HelloRequest};
use demo_greeter_service::Greeter;
use demo_greeter_service_grpc::greeter_client::GreeterClient;
use demo_greeter_service_grpc::greeter_server::GreeterServer;

tonic::transport::Server::builder()
    .add_service(GreeterServer::new(MyGreeter::default()))
    .serve(addr)
    .await?;

let mut client = GreeterClient::connect("http://[::1]:50051").await?;
let reply = client.say_hello(HelloRequest { name: "Fory".into() }).await?;

Java generation emits grpc-java service bases, stubs, and Fory codecs:

:::java
final class GreeterService extends GreeterGrpc.GreeterImplBase {
  @Override
  public void sayHello(
      HelloRequest request, StreamObserver<HelloReply> responseObserver) {
    HelloReply reply = new HelloReply();
    reply.setReply("Hello, " + request.getName());
    responseObserver.onNext(reply);
    responseObserver.onCompleted();
  }
}

Server server = ServerBuilder.forPort(50051)
    .addService(new GreeterService())
    .build()
    .start();

GreeterGrpc.GreeterBlockingStub stub = GreeterGrpc.newBlockingStub(channel);
HelloRequest request = new HelloRequest();
request.setName("Fory");
HelloReply reply = stub.sayHello(request);

The generated gRPC companions intentionally do not make gRPC a hard dependency of the core Fory language packages. Applications add the transport libraries they use: grpc-java for Java and Scala, grpcio for Python, grpc-go for Go, tonic/bytes for Rust, .NET gRPC packages for C#, @grpc/grpc-js or grpc-web for JavaScript, and grpc-java/grpc-kotlin for Kotlin.

Features

Bug Fix

Other Improvements

New Contributors

Full Changelog: https://github.com/apache/fory/compare/v1.1.0...v1.2.0

Source: README.md, updated 2026-06-13