Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.3
    • Component/s: core, jcr, mk
    • Labels:
      None

      Description

      i seems confusing to me that we are having multiple different json utilities in the
      current oak stack:

      • a dependency to google-json
      • a complete json utility including parser, json abstraction in oak-jcr (org.apache.jackrabbit.oak.jcr.json)
      • another json utility in org.apache.jackrabbit.mk.json containing tokenizer et. al.

      imo we should only have one single json utility and i would therefore suggest that
      we discuss this issue and try to reach a consensus which json-library we want to use.

      what do you think?

        Issue Links

          Activity

          Hide
          Julian Reschke added a comment -

          +1

          We also should make a conscious decision about whether we really do JSON, or just use JSON-like syntax. In the former case, we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.

          Show
          Julian Reschke added a comment - +1 We also should make a conscious decision about whether we really do JSON, or just use JSON-like syntax. In the former case, we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.
          Hide
          Thomas Mueller added a comment -

          +1

          There is json, and jsop (json-diff), which is a superset of json.
          We anyway need jsop, so we might not need the same tools in the json variant.
          As for jsop, what I wrote is:

          org.apache.jackrabbit.mk.json.JsopWriter

          org.apache.jackrabbit.mk.json.JsopReader

          • a low-level tokenizer with a stax-type interface
          • two implementations (JsopTokenizer and JsopStream),
            where JsopStream is very good for pipelining as it
            avoids to create/parse strings

          Plus we have org.apache.jackrabbit.oak.jcr.json.*, but unfortunately
          I don't have an overview about that currently. Some classes are named
          Jsop* and some Json* but it seems both can actually parse / generate jsop?
          Not sure if some of those classes only support json?

          Show
          Thomas Mueller added a comment - +1 There is json, and jsop (json-diff), which is a superset of json. We anyway need jsop, so we might not need the same tools in the json variant. As for jsop, what I wrote is: org.apache.jackrabbit.mk.json.JsopWriter the interface is basically JSONWriter http://www.json.org/javadoc/org/json/JSONWriter.html two implementations (JsopStream and JsopBuilder), we might not need JsopBuilder org.apache.jackrabbit.mk.json.JsopReader a low-level tokenizer with a stax-type interface two implementations (JsopTokenizer and JsopStream), where JsopStream is very good for pipelining as it avoids to create/parse strings Plus we have org.apache.jackrabbit.oak.jcr.json.*, but unfortunately I don't have an overview about that currently. Some classes are named Jsop* and some Json* but it seems both can actually parse / generate jsop? Not sure if some of those classes only support json?
          Hide
          Stefan Guggisberg added a comment -

          > we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.

          that's not the case anymore.

          "a node consists of an unordered set of name -> item mappings.
          each property and child node is uniquely named and a single name can only refer to a property or a child node, not both at the same time." [1]

          [1] http://wiki.apache.org/jackrabbit/RepositoryMicroKernel

          Show
          Stefan Guggisberg added a comment - > we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant. that's not the case anymore. "a node consists of an unordered set of name -> item mappings. each property and child node is uniquely named and a single name can only refer to a property or a child node, not both at the same time." [1] [1] http://wiki.apache.org/jackrabbit/RepositoryMicroKernel
          Hide
          Thomas Mueller added a comment -

          As a first step, I guess it would make sense to combine the low-level generators/tokenizer.
          The next step is unify the higher level stuff (working from bottom to top).

          I would volunteer to try to combine the low-level tokenizing / building of jsop.
          I would work together with Michi to do that.

          Show
          Thomas Mueller added a comment - As a first step, I guess it would make sense to combine the low-level generators/tokenizer. The next step is unify the higher level stuff (working from bottom to top). I would volunteer to try to combine the low-level tokenizing / building of jsop. I would work together with Michi to do that.
          Hide
          Julian Reschke added a comment -

          Stefan, MicroKernel#getNodes still says:

          • The collection of name/value pairs denoting child nodes is assumed to be
          • ordered.
          Show
          Julian Reschke added a comment - Stefan, MicroKernel#getNodes still says: The collection of name/value pairs denoting child nodes is assumed to be ordered.
          Hide
          Michael Dürig added a comment -

          The parsers in org.apache.jackrabbit.oak.jcr.json [1] grew out of of the need for parsers which are composable, extensible flexible and offer sufficient abstractions.

          [1] https://github.com/mduerig/json-jerk/blob/master/README.md

          Show
          Michael Dürig added a comment - The parsers in org.apache.jackrabbit.oak.jcr.json [1] grew out of of the need for parsers which are composable, extensible flexible and offer sufficient abstractions. [1] https://github.com/mduerig/json-jerk/blob/master/README.md
          Hide
          Thomas Mueller added a comment -

          Yes, the parsers at org.apache.jackrabbit.oak.jcr.json offer a higher level abstraction than what is in org.apache.jackrabbit.mk.json. Within MicroKernel implementations, possibly the low-level abstractions are sufficient (a StAX parser for example), but within other components the high-level abstractions (DOM based / event based) make sense. I believe the high-level abstractions could be built on top of the low-level abstractions.

          According to my tests, avoiding to generate String is a lot faster (as it completely avoids escaping / de-escaping and copying), and requires much less memory. This is the reason for JsopStream.

          I wonder if we should try to keep all json / jsop related stuff in one project, and if yes in which one.

          Show
          Thomas Mueller added a comment - Yes, the parsers at org.apache.jackrabbit.oak.jcr.json offer a higher level abstraction than what is in org.apache.jackrabbit.mk.json. Within MicroKernel implementations, possibly the low-level abstractions are sufficient (a StAX parser for example), but within other components the high-level abstractions (DOM based / event based) make sense. I believe the high-level abstractions could be built on top of the low-level abstractions. According to my tests, avoiding to generate String is a lot faster (as it completely avoids escaping / de-escaping and copying), and requires much less memory. This is the reason for JsopStream. I wonder if we should try to keep all json / jsop related stuff in one project, and if yes in which one.
          Hide
          Stefan Guggisberg added a comment -

          > Stefan, MicroKernel#getNodes still says:
          >
          > The collection of name/value pairs denoting child nodes is assumed to be
          > ordered.

          that's by an oversight. will fix asap.

          thanks

          Show
          Stefan Guggisberg added a comment - > Stefan, MicroKernel#getNodes still says: > > The collection of name/value pairs denoting child nodes is assumed to be > ordered. that's by an oversight. will fix asap. thanks
          Hide
          Michael Dürig added a comment -

          I removed the JSON parser in org.apache.jackrabbit.oak.jcr.json from the jcr bindings component at revision r1304539.

          Show
          Michael Dürig added a comment - I removed the JSON parser in org.apache.jackrabbit.oak.jcr.json from the jcr bindings component at revision r1304539.
          Hide
          Michael Dürig added a comment -

          Fixed at revision 1336035. The Google JSON parser is now only used as a reference parser in test cases for the Microkernel.

          Show
          Michael Dürig added a comment - Fixed at revision 1336035. The Google JSON parser is now only used as a reference parser in test cases for the Microkernel.

            People

            • Assignee:
              Unassigned
              Reporter:
              angela
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development