GSOC 2025 : 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.

[ghost]

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.

[GANESHSHARMA1]

Hi @erosb,

I’m really excited about this project to build a Java wrapper library for sourcemeta/blaze as part of GSoC 2025! I have experience with Java (e.g., developing REST APIs with Spring) and a keen interest in native C/C++ integration, which makes this a perfect fit for me. I’ve started exploring JNI basics and the sourcemeta/blaze codebase to get a head start.

I’d love to contribute by designing a Java-friendly API, implementing the JNI bindings, and ensuring the library is published to Maven Central with great documentation. I’m planning to submit a detailed GSoC proposal soon—would you be open to providing feedback on a draft? I’d also be happy to discuss the project scope or start with a small prototype if that helps.

Looking forward to hearing your thoughts! Thanks for mentoring this project.

[Sahith53]

Hi @erosb and mentors, I’m really excited about the GSOC 2025 project to build a Java wrapper for sourcemeta/blaze! I don’t have any experience with Java or C++ yet, but I’m super interested in learning and contributing to this. I’d love to get started—any tips or resources you recommend for a beginner like me? Looking forward to hearing from you!

[hamdy-fathi]

Hi @erosb and mentors, I am interested in this project I have much experience in both Java and C++ (major is c++ ), would like to know a bit more about this project and start on this, also please provide any additional docs . iam really looking forward to contribute in this project Thanks.

[Tanmay-Tripathi]

@erosb Hello, I am Tanmay and I’m genuinely excited about the project to build a Java wrapper library, bringing its high-performance JSON schema validation to the JVM ecosystem. Java has been my primary language for the past six years, and I’ve developed a deep understanding of the language alongside working with native libraries. The chance of creating an intuitive, developer-friendly API backed by Blaze’s speed — feels incredibly rewarding. I’m eager to contribute my skills to build a tool that makes schema validation faster, easier, and more accessible for Java developers everywhere. is this project going to be your priority ?

[erosb]

Hello @Tanmay-Tripathi @hamdy-cufe-eng @Sahith53 @GANESHSHARMA1 @drLite35 @Karan-Palan and anyone whom it may concern, please find the qualification task for this project below:

Implement PoC-level integration of a C++ library

Requirements:

• create minimal a java program that instantiates a C++ class
• the object should be an instance of a class that resides in a namespace
• for calling the native library, you can use FFM (preferred) or JNI (fallback)
• add a unittest verifying that the program works and returns the expected validation failure

Bonus points / Nice To Have requirements:

• instantiating a class in the sourcemeta::blaze namespace
• creating a library with maven or gradle
• showcasing both FFM and JNI
• creating GitHub Action workflow for testing & building the project
• implementing a testrunner that runs the json schema test suite on the wrapper library

[Tanmay-Tripathi]

hello @erosb i wanted to ask can we do this poc task for any c++ library for the purpose of demonstration or we should go on to clone and setup the codebase of sourcemeta/blaze and then do the poc ?

[erosb]

Hello @Tanmay-Tripathi , thanks for the question. Any c++ library can work, but using sourcemeta/blaze is a nice-to-have bonus point.

[GANESHSHARMA1]

Hi @erosb,

Implement PoC-level integration of a C++ library
Requirements:

- create minimal a java program that instantiates a C++ class
- the object should be an instance of a class that resides in a namespace
- for calling the native library, you can use FFM (preferred) or JNI (fallback)
- add a unittest verifying that the program works and returns the expected validation failure

Bonus points / Nice To Have requirements:

- instantiating a class in the sourcemeta::blaze namespace
- creating a library with maven or gradle
- showcasing both FFM and JNI
- creating GitHub Action workflow for testing & building the project
- implementing a testrunner that runs the json schema test suite on the wrapper library

Based on above requirements, I have started working on It. Soon I will submit PR.

[Honyii]

Our qualification task is live! Huge thanks to @erosb for putting this together. We’re excited to see your amazing submissions! Feel free to drop any questions or clarifications in the comments — happy contributing! 🚀

[princepal-dev]

@erosb @Honyii Heyyy, Prince this side, I completed the assignment.

[Dheerajmaddi]

Hello @erosb and @Honyii

I am Dheeraj with Full stack development expertise using Java, Spring Boot, React and JavaScript. This project, interests me to learn more about JSON Schema Org and contribute as a GSoC contributor for 2025.

What is the deadline to submit the qualification task Implement PoC-level integration of a C++ library?

[junaidzeb123]

Hi mentors and @erosb I have much intrest on building the java wrapper library. I have experience with Java (Spring) as well as c/c++. I have started working on above POC and started exploring the sourcemeta/blace codebase. Thanks.

[erosb]

Hello @Dheerajmaddi , according to the GSoC 2025 schedule the proposal deadline (which includes the qualification task) is Apr 8. @Honyii please correct me if I'm wrong :) thanks!

[princepal-dev]

@erosb Heyy, Prince this side, I completed the qualification task.

[Honyii]

Yes you're correct @erosb , application deadline is April, 8. GSoC timeline cc @Dheerajmaddi

[princepal-dev]

Yes you're correct @erosb , application deadline is April, 8. GSoC timeline cc @Dheerajmaddi

Hey @Honyii i completed the following work

• create minimal a java program that instantiates a C++ class
• the object should be an instance of a class that resides in a namespace
• for calling the native library, you can use FFM (preferred) or JNI (fallback)
• add a unittest verifying that the program works and returns the expected validation failure
• creating a library with maven or gradle
• creating GitHub Action workflow for testing & building the project
• implementing a testrunner that runs the json schema test suite on the wrapper library

what are the next steps

[Honyii]

@hustlerZzZ The next step is to submit your qualification task and start creating your proposal @erosb will share how/where to submit the task during the week.

[princepal-dev]

@hustlerZzZ The next step is to submit your qualification task and start creating your proposal @erosb will share how/where to submit the task during the week.

Okay thanks!

[Dheerajmaddi]

Yes you're correct @erosb , application deadline is April, 8. GSoC timeline cc @Dheerajmaddi

Thank you for the quick update @erosb and @Honyii, will work on it and keep you guys posted.

[hamdy-fathi]

Hello @erosb , i have completed the following requirements:

• create minimal a java program that instantiates a C++ class
• the object should be an instance of a class that resides in a namespace
• for calling the native library, you can use FFM (preferred) or JNI (fallback)
• add a unittest verifying that the program works and returns the expected validation failure

Bonus points

• showcasing both FFM and JNI
• creating GitHub Action workflow for testing & building the project

[Elctrony]

Hello I am interested in both C/C++ and Java how can I start contributing and get more info about the desired work?

[erosb]

Hello Everyone, in case you want to work on the qualification task, please make sure to:

• push it into a private GH repo
• share the repo with @jviotti and me ( @erosb )

Thank you!