🚀 Titanium JSON-LD 2.0 JSON Library Poll

[filip26]

We need to decide which JSON library to adopt for Titanium 2.0.

Options

• Jackson
• Gson
• Jakarta JSON (JSON-P / JSON-B)
• Other (please specify in comments)

---

Guidelines

• Share any insights, experiences, or preferences you have with these libraries.
• Consider performance, mutability, generation flexibility, or anything else you think is relevant.
• Vote for one option.
• Discuss pros/cons in the comments.

---

Vote and discuss below!

[imsdu]

Hello,

What were the reasons for choosing Jakarta JSON ? It could be an interesting insight to see if it should remain the underlying json library.

Besides Jakata Json pulled by Titanium, the classpath of my project contains Gson (via Apache Jena) and Circe (because it is written in Scala).

I would still opt for Jackson though as if I am not mistaken, it remains the most performant and the one with the most integrations out there.

Circe also provides a conversion to and from Jackson, I could get rid of the one I wrote for Jakarta.

However, several versions of Jackson 2.x are still used out there so that could mean having to support several of those.

They are also working on Jackson 3.x so that could be an option as they promise that it could coexist with 2.x:
https://github.com/FasterXML/jackson?tab=readme-ov-file#actively-developed-versions

Not sure what it looks like and when it will come out though.

[acoburn]

I would opt for Jackson. My sense is that it is the most widely used JSON processing library. And while I don't have any data to back up this statement, my understanding is that Jackson is also the most performant.

[filip26]

There might be another way to handle this. Please see Tree I/O, which provides a uniform API for reading tree data models across different formats and libraries.

As an example, see its use in Titanium JCS (note: this is the 2.0.0-SNAPSHOT version and has not been released yet).

[rvesse]

Personally I'd always choose Jackson for any JSON processing, it's just so ubiquitous and you have different levels of API for different use cases e.g. low level JSON streaming APIs that would likely be appropriate for something like this library, and all the higher level data binding APIs that you could also experiment with if it's preferable to get some generic tree structure to walk as opposed to using the low level APIs

[filip26]

Jackson has its own issues. Its popularity often leads to version conflicts. For example, a library used only for testing may require a different Jackson version than the main library, which can cause ObjectMapper to crash.

Jakarta JSON API, on the other hand, is generally a great fit, except for its strict immutability (including structure immutability), which can cause performance issues.

It is a shame that Java does not provide a unified abstract API for handling tree-like structures, or a scalar type that distinguishes between structures such as Map, List, and primitive values. I suppose JSON-P was an attempt to address this, but it did not succeed.

The only viable approach I see is to use a solution that is detached from any specific JSON parser or serializer and focuses purely on processing tree-like structures. That is exactly why TreeIO exists. It is not "clean by design", it intentionally relies on plain Object + adapters because there is no Scalar class/interface in Java.

FYI: Titanium + TreeIO works great with Jakarta. However, there are issues with Jackson that seem to require fine-grained configuration to produce properly deserialized JSON. The results of Jakarta and Jackson deserialization (with default settings) differ. Jakarta strictly follows the JSON specification, while Jackson does not and reusing an existing ObjectMapper leads to subtle failures in certain use cases.

[rvesse]

Jackson has its own issues. Its popularity often leads to version conflicts. For example, a library used only for testing may require a different Jackson version than the main library, which can cause ObjectMapper to crash.

Oh sure, but that's a problem common across the Java ecosystem.

However increasingly with awareness of the costs of vulnerabilities, supply chain attacks etc most serious users are getting much more onboard with having to proactively keep all their dependencies up to date and not mix versions.

However, there are issues with Jackson that seem to require fine-grained configuration to produce properly deserialized JSON. The results of Jakarta and Jackson deserialization (with default settings) differ. Jakarta strictly follows the JSON specification, while Jackson does not and reusing an existing ObjectMapper leads to subtle failures in certain use cases

Would Titanium not own the ObjectMapper and thus be able to customise it to produce "compliant" JSON from your perspective?

[filip26]

Would Titanium not own the ObjectMapper and thus be able to customise it to produce "compliant" JSON from your perspective?

That’s not really the issue. The challenge is that with the vanilla ObjectMapper, some test cases fail, and I don’t currently have the capacity to support users who might encounter issues due to specific configuration requirements or to investigate complex bug reports. The wide range of Jackson versions in use also adds to the complexity.

A library like Jackson or Titanium needs to be careful with its release cycle.

Version 2.0 will make it possible to implement your own adapter, so anyone interested in using Jackson or Gson will be able to do so.

I started this project in good faith, but over time it has required more personal investment than expected, over $200K so far. Unfortunately, I’ve come to realize that open source is often heavily exploited for profit, and that makes it difficult to sustain meaningful work in the long term.

[hathiphant]

Possibly useful: https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145905.html

It is a shame that Java does not provide a unified abstract API for handling tree-like structures, or a scalar type that distinguishes between structures such as Map, List, and primitive values. I suppose JSON-P was an attempt to address this, but it did not succeed.

[filip26]

If you are interested in the 2.0.0 version line, please check out 2.0.0-M1. It includes support for Jakarta and Jackson2. see JacksonTestSuite and JakartaTestSuite for details.

There is still a lot of work to be done before the proper 2.0.0 release. Please note that milestone releases are not stable, new milestones may introduce breaking changes and are generally not recommended for production use.

Feel free to open an issue or submit a pull request.