On 2015-01-05 11:23, Julian Reschke wrote:
On 2015-01-05 10:11, Thomas Mueller wrote:
Hi,
oak.commons.json is currently also used in MicroKernelImpl, and the
persistent cache in the DocumentNodeStore. In my experience, the classes
JsopBuilder, JsopTokenizer, and JsopStream are much faster and need less
memory than org.json.simple, because they use low level "streaming", and
not a 1:1 JSON-object-to-Java-object representation. JsonObject (which
Yes, that's one of the reasons why I stopped using org.json.simple for
serialization.
does support that) is only used for testing; I guess that class could be
moved to the test module.
1) Is oak.commons.json supposed to support all of JSON?
Yes. But actually I don't understand why you ask the question. Do you
want
to interface with another JSON tool?
I just don't want to bind me to something that is not a proper JSON
implementation :-)-
2) If I switch the RDB code to use it, would it be ok to extend/tune it
to meet my specific requirements (with respect to APIs), when needed?
What is missing? I think whatever is needed (for high performance JSON
processing) should already be there.
OK; thanks for confirming; I'll have a closer look then.
Best regards, Julian
...after having had a closer look...:
1) I feel uncomfortable about using something for JSON that has been
written for a different purpose (JSOP), allowing certain extensions I
definitively don't want to use.
2) For parsing, it seems that the only thing I *could* use is the
JsopTokenizer, which a) does not seem to do anything than strings (this
is probably by design, as it is just a tokenizer), and is also very weak
on documentation (what is the parameter for "read(int)"?).
3) JsopBuilder escapes many characters that do not need to be escaped.
If this is supposed to provide JSON support for Oak, it definitively
needs work...
Best regards, Julian
PS: I like the pull-parsing aspect.
