Adopting a third-party JSON library

Hi,
I'm a new contributor. I'm considering the possibility of adopting a third-party JSON library instead of LLVM's homegrown `lib/Support/JSON.cpp`. The way I see it, this would bring several advantages as well as some downsides:

+ Slimmer codebase.
+ Benefit from upstream work and active contributions to another project.
+ Possibly improved performance and API ergonomics.
- Likely compile times regression as many JSON libs are header-only.
- Risk of introducing bugs and breakages across LLVM.

As far as I can tell, these are the most popular C++ JSON libs:

* https://github.com/nlohmann/json
* https://github.com/open-source-parsers/jsoncpp
* https://github.com/Tencent/rapidjson

I'm trying to understand if this is something I should work on and whether or not it would benefit the project.

Filippo Costa

LLVM's pretty slim on external dependencies, which makes it a bit
easier to build, etc - though, admittedly, that's perhaps a nicer
justification for the sort of "Not invented here" problem that leads
to the kinds of problems you've mentioned. (at the moment, the only
library dependency I know of in mainline LLVM is zlib, which is
optional - other dependencies we carry within the LLVM project, like
gtest (with all the issues with that - forked codebase, not getting
new features, etc))

Two issues that come up with using external libraries just off the top of my head:

  1. Licensing - it’s unlikely any of the external libraries use the LLVM license, so there would potentially need to be legal vetting, both by the LLVM foundation, and every downstream vendor of LLVM.

  2. Updating - how often do we update the external library? What if there’s a bug fix we need to the library, but it isn’t in an official release yet? What if the upstream library decides to drop support for something we still need/require support for something we don’t yet support (e.g. moving to C++17 before LLVM does)?

Beyond that, I’d want to see evidence that any external library is actually better than LLVM’s homebrew one. For example, you say that we might see improved performance. This is true, but we might also see WORSE performance - there needs to be research showing that the performance is better.

In addition to the points made by James and David. I also would like to highlight that since JSON is not in the critical path of LLVM’s codebase (i.e. it’s mostly used in tools for LLVM’s developers), if the current lib/Support/JSON.cpp is good enough in terms of performance and code quality, then I don’t think we want to add unnecessary complexities from third-party libraries. Improvements and solutions should always be driven by critical problems, not the other way around.

Of course, if you have any concrete material to prove your points (e.g. performance comparison or maintainability study). We would love to see :slight_smile:

Thank you
-Min

lib/Support/JSON.cpp has been written because the community did not want to add an external dependency or copy a 3rd party JSON library. See http://lists.llvm.org/pipermail/llvm-dev/2017-October/118583.html for th discussion. Since JSON.cpp now is integrated in the codebase, there now is even less reason to switch to a 3rd party implementation.

Michael