llvm dev - Aug 2020 - 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))

On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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 Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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.

On Wed, 19 Aug 2020 at 04:42, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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))
>
> On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > 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 Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200819/cf40ee3b/attachment.html>

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 :-)

Thank you
-Min

On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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 Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Min-Yih Hsu
Ph.D Student in ICS Department, University of California, Irvine (UCI).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/d96cace7/attachment.html>

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

Am Di., 18. Aug. 2020 um 22:31 Uhr schrieb Filippo Costa via llvm-dev <
llvm-dev at lists.llvm.org>:
> 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 Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/6c2060ae/attachment.html>