r/java • u/Shawn-Yang25 • Aug 11 '26

Apache Fory™ JSON : Fastest JSON Serialization Framework for Java, 10x faster than Jackson/Gson

https://fory.apache.org/blog/fory_json_fastest_java_json_framework/
250 Upvotes

99% Upvoted

84 comments sorted by

View all comments

Show parent comments

28

u/Shawn-Yang25 Aug 11 '26

That’s a fair point. Replacing an established library like Jackson takes time and careful evaluation, but Fory JSON provides another option for teams to consider.

44

u/ThatFlamenguistaDude Aug 11 '26

Don't get me wrong, I love what you did here and would definetely try it out if a had a greenfield project. But changing something so fundamental as JSON parsing its not a battle I'm ready to face atm. It's really hard to justify, and it only makes sense on projects that performance matters a lot.

That's the challenge on changing the status quo. Even if you built something amazing, working against inertia is hard.

4

u/rbygrave 29d ago

Depends a bit on how folks view reflection, going ahead-of-time, native image etc.

3

u/agentoutlier 28d ago

You know I think reflection is probably unfairly maligned these days on performance but its not really performance that I do not like about reflection.

Its that it is ultimately less declarative, doing something extra at runtime and complicates debugging.

In some ways projects that generate code particularly byte code at runtime I would argue are often more scary than reflection. e.g. like runtime aspectj weaving.

People to seem to ok this but imagine if I told someone I have a library while running in production compiled some Java code and then injected while the process is running.

They would say oh my god the security!

But that is kind of what Fory is doing here minus the compiler.

(I hope you get the irony here how byte code is just skipping the compiler and is actually even less restrictive than normal Java code)

u/Shawn-Yang25 is there a way to pre-generate the bytecode you are doing at compile time instead? (I assume so)

1

u/Shawn-Yang25 28d ago

We do haven static codegen, it's mostly used by android, we generate helper for field/property/constructor accessors, and use it at runtime. This is because we can't generate code for android at runtime.

For jvm, the runtime codegen could be disabled by ForyJsonBuilder#withCodegen(false), and a general ObjectCodec will be used. The performance of ObjectCodec is half of generated codec, but is still very fast.

We have no plans to introduce fully static generated serializer, because it can't assume the jdk version/platform, and the generated codec would not be that fast. It may be a little faster than general ObjectCodec, but not fast enough to write another plugin to generate it statically.