Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0-pr
    • Fix Version/s: 1.0-pfd
    • Labels:
      None

      Description

      The current design limits possible performance improvements that could be obtained by custom parser implementations. A cleaner design would let the implementation provide both parser and object model implementations that are better integrated and higher performing.

      If we implement http://java.net/jira/browse/JSON_PROCESSING_SPEC-9 a json structure could consist of a mix between implementations from the api package and implementation defined classes.

      Builders would be created by static methods of the Json class or a JsonBuilderFactory created via the Json class.
      JsonReader would require a JsonReaderFactory with similar methods to JsonParserFactory.

      Discussion at http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/9 and http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/54

        Activity

        jhorstmann created issue -
        Hide
        jitu added a comment -

        Since JsonParser/JsonGenerator are already used by JsonReader/JsonGenerator, most of the performance improvements are available from a provider. Perhpas, the remaining improvements for JsonString/JsonNumber impl may not be much.

        The high-level API should more usable than the low-level API, i.e new JsonArrayBuilder() etc is more user friendly.

        Otherwise, a possible approach is to introduce
        JsonReaderFactory, JsonWriterFactory, JsonBuilderFactory, and all possible methods on Json. That seem bit heavy-weight to me and not justify the performance benefits.

        Show
        jitu added a comment - Since JsonParser/JsonGenerator are already used by JsonReader/JsonGenerator, most of the performance improvements are available from a provider. Perhpas, the remaining improvements for JsonString/JsonNumber impl may not be much. The high-level API should more usable than the low-level API, i.e new JsonArrayBuilder() etc is more user friendly. Otherwise, a possible approach is to introduce JsonReaderFactory, JsonWriterFactory, JsonBuilderFactory, and all possible methods on Json. That seem bit heavy-weight to me and not justify the performance benefits.
        jitu made changes -
        Field Original Value New Value
        Fix Version/s 1.0-pr [ 16133 ]
        Affects Version/s 1.0-pr [ 16133 ]
        Hide
        wenshao added a comment -

        i can not understand why not be interfaces?

        not just these two, should be interfaces include following:
        JsonReader
        JsonWriter
        JsonArrayBuilder
        JsonObjectBuilder

        Show
        wenshao added a comment - i can not understand why not be interfaces? not just these two, should be interfaces include following: JsonReader JsonWriter JsonArrayBuilder JsonObjectBuilder
        Hide
        jhorstmann added a comment -

        The current design, with only JsonParser as an implementation provided class, also seems to have performance problems of its own due to repeated ServiceLoader lookup. With JsonReader as an interface and a threadsafe JsonReaderFactory these lookups can be avoided.

        Discussion at http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/2

        Show
        jhorstmann added a comment - The current design, with only JsonParser as an implementation provided class, also seems to have performance problems of its own due to repeated ServiceLoader lookup. With JsonReader as an interface and a threadsafe JsonReaderFactory these lookups can be avoided. Discussion at http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/2
        jitu made changes -
        Fix Version/s 1.0-pr [ 16133 ]
        jitu made changes -
        Fix Version/s 1.0-pfd [ 16271 ]
        Hide
        jitu added a comment -

        One suggestion was to cache the provider so that there won't be service lookup costs for each JsonReader/JsonWriter. The cache strategy that is suggested is:
        "The cache should be a ThreadLocal, and the cached value should include
        a reference to the class loader that was used to look up the provider,
        presumably the thread-context class loader. Use the cached provider only
        when the saved class loader matches the one that you'd use if you were
        going to look it up again."

        Show
        jitu added a comment - One suggestion was to cache the provider so that there won't be service lookup costs for each JsonReader/JsonWriter. The cache strategy that is suggested is: "The cache should be a ThreadLocal, and the cached value should include a reference to the class loader that was used to look up the provider, presumably the thread-context class loader. Use the cached provider only when the saved class loader matches the one that you'd use if you were going to look it up again."
        Hide
        jitu added a comment -

        Made JsonReader, JsonWriter, JsonArrayWriter, JsonObjectWriter as interfaces.
        Added JsonReaderFactor, JsonWriterFactory, JsonBuilderFactory interfaces to create these objects.

        Added methods to create these objects as well as the factory classes.

        Show
        jitu added a comment - Made JsonReader, JsonWriter, JsonArrayWriter, JsonObjectWriter as interfaces. Added JsonReaderFactor, JsonWriterFactory, JsonBuilderFactory interfaces to create these objects. Added methods to create these objects as well as the factory classes.
        jitu made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee jitu [ jitu ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            jitu
            Reporter:
            jhorstmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: