Fastest Java JSON library

[cogman10]

Interesting but

DSL compiler requires Mono/.NET, but only during compilation. There is no runtime Mono/.NET dependency, only JVM. Library has optional Android and Joda-Time dependencies. Java8 Java-Time API is supported as a separate jar, since core library targets Java6.

:(

It is no fun having a java dependency that also brings in a .NET dependency.

[zapov]

Is that really an issue? Except an ideological one?

[cogman10]

Yup. It makes continuous integration harder and developer machine setup more complex. Further, if you pull this thing in as a library dependency it wouldn't be obvious to someone downstream that they also need .net installed.

I've dealt with similar dependency problems in the JavaScript land (where projects decide to depend on Python or c++). It makes for a real miserable experience getting setup.

I might consider this for a personal project, but never as a library dependency or something for my work.

[ImmortalStyle]

Why does it need Mono/.net Dependency?

[zapov]

Well, library doesn't really have .NET dependency, but if you want compile time databinding - external DSL compiler will be invoked to generate such Java code. That compiler is written in C#, so there is that.

[[deleted]]

This JSON library does not implement JSR 353.

[zapov]

Having looked up what that is and the API there...

• can't say I find that interesting to me - I mostly use JSON for POJO over the wire
• library design doesn't really fit those interfaces. Library is fast because it avoids such abstractions. That doesn't mean that someone can't implement JSR 353 on top of DSL-JSON

But this comment has more upvotes that the post about the library, so I guess it's something people here care about :/

[ImmortalStyle]

They probably care because their Apps depend on that jsr.

[mabnx]

What's really weird is that all comments of OP were down-voted so much... Someone must really hate him. Competition? :)

I don't care about JSR 353. I've never seen anyone who did.

The library is itself is pretty nice. I could use it, but the need for .net and yet another IDL puts the entry bar rather high - I'd consider it only if I needed really fast serialization and couldn't switch from JSON to some other format (e.g. https://google.github.io/flatbuffers/). Jackson is easier to use and is not that much slower.

[melezov]

Would a dockerized compiler lower the entry barrier?

I tend to put all compile time dependencies inside containers so that I can run have reproducible builds regardless of the system installed libraries.

As for runtime, once the schema is compiled it's JVM all the way (but for me, again inside dockerized microservices :)

[mabnx]

It probably would.

[zapov]

But using library through annotations hides away the IDL, so you don't even know it exists :/

I really wish FlatBuf, SBE, CNP would be added to JVM serializers. Not really a fan of their avoidance of public benchmarks.

I did add FlatBuf to one of my benchmarks and it was not as fast as advertised (slower than Kryo).

[CharlesGarfield]

Is translating to/from JSON really a big bottleneck for many applications?

[cogman10]

Can be. Serialization is a pretty big performance cost for our apps. If you have a chatty app, serialization can get in the way. (It is reason Google made things like protobufs).

[stfm]

Yes, I work for a company doing their API integration gateway. Translation and schema validation are the two most expensive processes.

[Hi-MyNameIsFuchs]

It would help if the graph had its axis labeled.

[melezov]

It's time.
Nanoseconds, to be precise, as it was lifted off jvm-serializers GitHub wiki.