Build a Java wrapper library for sourcemeta/blaze

[erosb]

Build a Java wrapper library for sourcemeta/blaze

Brief Description
sourcemeta/blaze is a high-performance json schema validation library. The goal of this project would be making it available on the JVM platform by building a wrapper library around it, and publishing it on maven central.

Expected Outcomes
A java library should be available on maven central that has a Java-friendly API, and use sourcemeta/blaze under the hood for performing json schema validation.

Skills Required

Interest both in java and native c/c++ libraries, DX and documentation.

Mentors

@erosb

Expected Difficulty
Medium

Expected Time Commitment
175 hours

[jviotti]

Hey @erosb, thanks for suggesting this! Just some misc notes:

• The project that implements the validator is https://github.com/sourcemeta/blaze. The JSON Schema CLI just offers a simple opinionated interface to it
• I don't know almost anything about Java, but happy to attempt to help 😅
• Note that Blaze is an AGPL library, so the Java bindings would be AGPL as well (just pointing that out!)

Also, one of the main challenges we saw when attempting Blaze bindings to other programming languages is converting the JSON inputs from whatever the programming language JSON implementation is to the JSON implementation that Blaze expects. In cases like Node.js, converting a v8 JSON object to a Sourcemeta JSON object was expensive enough to counter the performance benefits of Blaze. Do you have any insights on how to do this in a performant manner in Java?

[erosb]

Hello @jviotti thanks for the feedback!

The project that implements the validator is https://github.com/sourcemeta/blaze

Thanks, updated the issue title and description accordingly

I don't know almost anything about Java, but happy to attempt to help

sounds good, I don't know almost anything about C++ so it will be perfectly fine :)

Note that Blaze is an AGPL library, so the Java bindings would be AGPL as well

No problem with that

In cases like Node.js, converting a v8 JSON object to a Sourcemeta JSON object was expensive

I don't have any input about the mapping overhead. Probably this heavily depends on the complexity of the schema and the size of the instance. If it turns out to be severe, I think it should be possible to implement a json parser as part of this library, which directly parses a json string into a sourcemeta json object.

[Karan-Palan]

Hey mentors, this idea interests me. However I do not have experience in Java. I'd like to however try and work on this. Will start learning java, any specifics that I shall learn?

[jviotti]

I don't have any input about the mapping overhead. Probably this heavily depends on the complexity of the schema and the size of the instance. If it turns out to be severe, I think it should be possible to implement a json parser as part of this library, which directly parses a json string into a sourcemeta json object.

@erosb Yeah, this sounds good. Blaze has its own JSON parser and the bindings can just take a JSON string, and do everything internally with Blaze stuff 👍🏻

[erosb]

Helo @Karan-Palan , beside learning java in general, the specific skills this project will need are

• Java Native Interface
• and/or Foreign Function and Memory API

[Karan-Palan]

Thanks for the reply! I'll learn and create some projects using them

[jdesrosiers]

Also, one of the main challenges we saw when attempting Blaze bindings to other programming languages is converting the JSON inputs from whatever the programming language JSON implementation is to the JSON implementation that Blaze expects. In cases like Node.js, converting a v8 JSON object to a Sourcemeta JSON object was expensive enough to counter the performance benefits of Blaze.

I encountered the same kind of thing when I looked into options for JSON Schema in web assembly. Sending anything other than primitives to web assembly is expensive. But, not only that, you have to also have some libraries for working with structured data in web assembly as well. For example, if using Rust for generating the web assembly, you'd need the rust standard library included. That's bigger than my whole implementation and size matters on the web. It didn't seem like there was reasonable path forward, so I abandoned the effort.

I hope this works out better. My guess is that there will be some point were the validation gets complex enough that it becomes faster than existing Java libraries, but relatively simple cases will probably remain faster in Java due to the translation cost. It will be interesting to see where that line ends up. However, I suspect that its possible for a Java library to be optimized to the degree Blaze is and get close enough performance that it's never going to be worth the translation. I'm sure there doesn't exist a Java implementation that's optimized to that level, but I think it's possible. Java can be quite fast if you're diligent/obsessive enough.

[drLite35]

Hi @erosb and mentors, I am interested in this project I have some experience in both Java and C++, would like to know a bit more about this project and start on this, if there is any additional doc/support you can provide me with, it will be helpful, meanwhile let me go through aforementioned.
Thanks.