IIUC there were supposed to be memory advantages to noggit. I have not seen this quantified, and the relevance of those advantages over current jackson (vs libs available in the early 2000's) seems like a valid thing to investigate.
Unfortunately, we have areas where we support json with duplicate keys, which while technically legal JSON is unexpected by most default parser usages and an anathema for mapping the json into an object in an object oriented language. We also support extra trailing commas in lists which violates the spec IIUC. It's hard to justify a change until 1. there is a demonstrated performance advantage, or 2. those API's have been redesigned, or 3. Someone takes the time to figure out how to make Jackson play nice with the oddities we support, and writes reusable utilities to ensure consistency so that it's transparent to users On Mon, Aug 5, 2024 at 11:53 AM David Smiley <dsmi...@apache.org> wrote: > We have a couple JSON Parsing libraries -- "Noggit" (internal to Solr) > and "Jackson". Noggit is more lenient in parsing. I suppose Solr > should use Noggit for parsing JSON coming into it, but AFAIK Solr only > returns/emits valid JSON; yes? For parsing JSON that we assume is > compliant (e.g. from Solr), should we prefer Jackson or Noggit? Are > there performance advantages? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
