Support Go-JSON

[zeripath]

This PR provides a mechanism to select the JSON library at start-up, on configuration and at compile time.
Go-JSON support is also added.

Signed-off-by: Andrew Thornton art27@cantab.net

[zeripath]

0.5.0 is out so I'll try to update this again at some point

[zeripath]

OK I've updated this and made the JSON library selectable.

[silverwind]

Seems a bit overkill to me to have it runtime-selectable, but I guess we can just remove that option once we settle on a module.

Is there an easy way to have at least a subset of tests run on all implementations?

[lunny]

I also think the end users should not need to know how to chose a json encoder/decoder. It's could be a build tag but not a config item.

[wxiaoguang]

I also have the question why do we need to make JSON library configurable. There might be other configurable libraries like YAML, INI, ORM ....

Does it bring more benefits than the complexity?

[lunny]

Sorry I will against make it configurable for end users. It should be a build tag.

[wxiaoguang]

Sorry I will against make it configurable for end users. It should be a build tag.

I would not even introduce a build tag. If I find something is good enough, I will just use it to replace the old.

If there is no real benefit, we do not need to introduce too many options/tags.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[silverwind]

Just checking the issue tracker of go-json, it still has crash bugs.

I suggest sticking to encoding/json, as it will receive much more developer attention than those unstable/abandoned hobby projects and is bound to only get faster over time.

[lunny]

Just checking the issue tracker of go-json, it still has crash bugs.

I suggest sticking to encoding/json, as it will receive much more developer attention than those unstable/abandoned hobby projects and is bound to only get faster over time.

I suggest we can close this one and open a new when something is ready. @zeripath

[zeripath]

When I last updated and fixed this PR go-json was working completely fine for Gitea - but the potential issue of there being bugs was a reason why I provided the configuration variable which @lunny did not like.

@silverwind we're already using json-iterator over encoding/json and I would note that encoding/json has not increased in speed significantly for the entire period time I have been involved in gitea.

However, it's clear that this PR is not going to be merged so I will close it.

[silverwind]

I recommend dropping json-iterator as well. It has a number of mind-bogging bugs, just check their issue tracker. Gitea might not hit them currently, but it can in the future.

[zeripath]

There is a considerable time penalty to using encoding/json over jsoniterator. You are more than welcome to write the PR and fix the multiple issues were we have relied on jsoniterator error interpretation (this PR has the fixes for those) and then do the performance tests to prove this.

IN FACT: Precisely this PR would have allowed for that test to be made and to allow us to consider dropping to encoding/json keep jsoniterator or try out go-json - without even re-compiling. And if it had turned out that jsoniterator/go-json were causing too many bugs support could have been simply dropped etc.

[silverwind]

I guess we shouldn't try to fix what aint broken then.

On topic of benchmarks, I do find https://medium.com/geekculture/my-golang-json-evaluation-20a9ca6ef79c from 2021, so I guess you are right, encodings/json is worst: