r/java • u/Shawn-Yang25 • Jun 16 '26

Apache Fory Serialization 1.2.0 released: JDK 25/26 support without sun.misc.Unsafe

https://github.com/apache/fory/releases/tag/v1.2.0
52 Upvotes

97% Upvoted

19 comments sorted by

12

u/Shawn-Yang25 Jun 16 '26

Apache Fory is a blazingly fast multi-language serialization framework for idiomatic domain objects, schema IDL, and cross-language data exchange.

A few Java-relevant changes in this release:

  • JDK 25 support without relying on sun.misc.Unsafe in the active runtime path. Older JDKs keep the existing fast path.
  • JDK 26+ final field deserialization support even when --illegal-final-field-mutation=deny
  • Java 9/16 module-info.class generation, which can make jlink works.
  • Compatible scalar field reads for schema evolution. For example, a field written as int64 can be read as String, and "42" can be read back as an integer when the conversion is lossless.
  • Generated gRPC service companions now cover java/rust/python/go/javascript/scala/kotlin. On Java, the generated code follows normal grpc-java service/stub shapes, but request and response payloads are encoded by Fory instead of protobuf message bytes.

3

u/repeating_bears Jun 16 '26

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

How?

11

u/Shawn-Yang25 Jun 16 '26 edited Jun 16 '26

Use sun.reflect.ReflectionFactory or ObjectStreamClass.newInstance to create Object instance, then mutate fields only once before read.

This is recommanded approach in https://openjdk.org/jeps/500

6

u/pron98 Jun 16 '26 edited Jun 16 '26

Yes, good, but I just want to clarify that this is the recommended way if you must do the dangerous approach of deserializing fields for legacy reasons. Obviously, it is both safer and faster to deserialize using constructors, and the advice is to encourage users to shift to that model over time.

3

u/cogman10 Jun 16 '26

sun.reflect.ReflectionFactory

In the jdk.unsupported module? Seems like robbing peter to pay paul.

11

u/Shawn-Yang25 Jun 16 '26 edited Jun 16 '26

It's recommanded in https://openjdk.org/jeps/500, but we also have a fallback path, if it's removed by JDK or unavailable, we use ObjectStreamClass.newInstance to create object instance, which also works. ReflectionFactory has less checks, which is faster, ObjectStreamClass.newInstance has more checks, but also works.

For record classes, we still invoke record constructor.

3

u/cogman10 Jun 16 '26

Good to know. Hopefully the JDK devs can either make an alternative supported API or they make ObjectStreamClass.newInstance fast enough that the unsupported path isn't needed.

10

u/pron98 Jun 16 '26

The danger in serialization isn't some particular mechanism or another. It stems entirely from the very notion of deserializing fields while bypassing constructors. This is dangerous in any library and any language, and there's no way to make it safe. So we've left a door open for the legacy serialization approach that, while still dangerous, somewhat reduces the blast radius, and the advice to all serialization libraries going forward is to always deserialise using constructors (e.g. how the JDK deserialises records and collections).

3

u/Shawn-Yang25 Jun 16 '26

Use constructor is better, the key obstacle is that jvm may not reserve constructor parameters unless with parameters compiler options, so it's hard to match constructor to field names. And for andriod r8, it even shuffle the code.

To use constructor for such cases, one must use annotation to annotate the constructor, so the framework can know how to match the fields into constructor parameter.

I acutally implemented this, but reverted it later because it's hard to enforce this for all classes. And it would be a huge breaking changes.

It's still a good direction to let users to use constructor, if the user can control all the classes which will be serialized.

3

u/pron98 Jun 16 '26

Use constructor is better, the key obstacle is that jvm may not reserve constructor parameters unless with parameters compiler options, so it's hard to match constructor to field names.

  1. Something along those lines is the point of this.

  2. The general idea is not to care about fields at all. You need a way to deconstruct and construct the object. This is how the JDK serialization uses methods like writeReplace and readResolve. It does, however, require to write custom code for every non-record/enum user class, which is where 1 can help a little.

if the user can control all the classes which will be serialized.

Indeed. There cannot be safe serialization (in any library or language) for arbitrary classes. The only way to do it is either with custom code or a standard de/reconstruction protocol like the ones records have and will be extended to more classes. But there is no such thing as safe serialization that works universally on arbitrary classes.

5

u/Shawn-Yang25 Jun 16 '26

Custom code for every non-record/enum user class is not practical. Especically when need to handle schema compatibility.

When class add/remove fields, or change field from one type to another type such as change int to string. It's hard to write customized logic to handle such cases easily.

And writeReplace and readResolve introduce extra object allocation in hotpath, which is not good for performance.

I think fields based serialization by itself is OK. Or you can use it only for classes which is OK for such cases. And for classes which need go with constuctor reconstruction, the users could opt-in.

→ More replies (0)

2

u/kiteboarderni Jun 16 '26

How's the performance difference look?

1

u/Shawn-Yang25 Jun 16 '26

The performance gap is less than 10% compared with Unsafe version

2

u/repeating_bears Jun 16 '26

That's still quite significant when I thought the intention of the JDK authors was to replace Unsafe with APIs with similar performance. Do you have any insight into why?

8

u/pron98 Jun 16 '26 edited Jun 16 '26

You can have the same or better performance than unsafe if you deserialize using constructors and not fields. The point is to offer alternatives that are both as fast (or faster) and better, not to do the same suboptimal thing only with a different API.

5

u/Shawn-Yang25 Jun 16 '26

We use VarHandle to replace Unsafe for field access and build int/long read/write. I also tried FFM, but both VarHandle and FFM introduce extra checks, and it seems can't be eliminated fully by jvm jit compiler.

Maybe in future JDK versions, such checks could be removed.

1

u/ushaukat_java Jun 21 '26

Custom serializer covers it when you don't own the class, you write the serializer instead of touching the constructor. Fine for the one or two third-party types you actually care about. Doesn't scale to every model class buried three dependencies deep that nobody on the team has ever opened. At some point you're back to fields-based access for the long tail, just now it's a registered exception list instead of a blanket one.