Skip to main content

[json-processing-spec users] Re: Remaining work in JsonParser

  • From: Tatu Saloranta < >
  • To:
  • Subject: [json-processing-spec users] Re: Remaining work in JsonParser
  • Date: Wed, 21 Nov 2012 11:32:10 -0800

On Tue, Nov 20, 2012 at 10:44 PM, Jitendra Kotamraju
< >
 wrote:
> I am working on incorporating the all the discussed changes and make a draft
> ready for public review phase. In the meantime, I want to make some progress
> on the JsonParser changes that were discussed in various threads. Let me
> know if we want to consider any of these.
>
> * iterator() gives iterator of events. But these events are *not*
> self-contained items like Map.Entry, so that looks odd to call some methods
> on parser object and some methods on iterator object.
> Since this more of cursor API (rather than iterator), should we consider two
> separate methods ?
>
> boolean advance() instead of hasNext()
> Event getEvent() instead of next()
>
> * incremental processing of strings that are large. Some of you felt this is
> useful.

Right -- not so much for performance, but for scalability and low
latency when dealing with CLOBs/BLOBs. Not a very common case, but
something I have used myself and that has been requested.

> * skipValue()
> This is primarily a convenience method and can be implemented using other
> methods. So should we consdier this ?

Not only convenience actually -- as others mentioned, for performance,
since this can avoid most of object allocations, and (when properly
implemented) even byte->char decoding.

> * We have a JIRA issue, that moves the cursor to certain place and creates a
> corresponding
> JsonValue
>
> /*
> getJsonValue(JsonObject.class) is valid in START_OBJECT state, moves cursor
> to END_OBJECT
> getJsonValue(JsonArray.class) is valid in START_ARRAY state, moves cursor to
> END_ARRAY
> getJsonValue(JsonString.class) is valid in VALUE_STRING state
> getJsonValue(JsonNumber.class) is valid in VALUE_NUMBER state
> and other values
> */

Since these are not exactly regular getters, maybe some other names
would be better. Not sure what, but something like "nextValue()" (or
decode/build/parse/collectValue) would indicate that it actively
advances stream. I know that Stax used "getElementText()", but that
lead to quite a bit confusion for
novice users who thought it'd be DOM style, and not affect the stream.

One more thing: is there no way to access Location information? This
is important for error messages; not just ones parser/reader throws a
exceptions, but for calling code, when indicating validation problems.
This should give access to row/column numbers and perhaps source --
see
Stax for examples.
This is an area that many parsers skimp on, but there's nothing more
frustrating than trying to track down a validity issue in
multi-megabyte file, without having good location information.

-+ Tatu +-


[json-processing-spec users] Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Remaining work in JsonParser

Jörn Horstmann 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Remaining work in JsonParser

Jörn Horstmann 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Remaining work in JsonParser

Jitendra Kotamraju 11/26/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Eugen Cepoi 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Tatu Saloranta 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Tatu Saloranta 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Jitendra Kotamraju 11/26/2012
 
 
Close
loading
Please Confirm
Close