Skip to main content

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

  • From: Jitendra Kotamraju < >
  • To:
  • Subject: [jsr353-experts] Re: [json-processing-spec users] Re: Remaining work in JsonParser
  • Date: Wed, 21 Nov 2012 12:26:17 -0800

On 11/21/2012 01:03 AM, Jörn Horstmann wrote:

Zitat von Jitendra Kotamraju 
< >:
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()

The method names in the iterator interface are short and intuitive, but I would suggest that JsonParser should directly implement iterator instead of providing an iterator() method. This should make it clear that the event stream is not restartable and that the parser and iterator methods are closely related. I think this is also the approach used in the interface.
The events in XMLEventReader are self-contained. Once you have the event, you can get all the information from that event. For example, using startElement event, we could get element name, attributes etc.

Here it is not the case. Also, people felt that this is not really a iterator.

* incremental processing of strings that are large. Some of you felt this is useful.

I haven't yet come across Json data where streaming access to strings would be required or give a big performance improvement. However, a naive version of a getReader method would be really simple to implement, while giving other

You also seem to indicate that this is not a common usecase. Then I wouldn't want to consider it for this version.

JsonParser implementation the opportunity to create better performing versions.

* matchName(String)
May be used for performance. I don't want to consider other match methods that match both name and value

I did not follow the discussion on matchName that closely, so the other experts have to comment on this one.

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

I think this might be useful as a method of JsonParser since its implementation could avoid most object allocation. An utility method in another class would not have that option. A simple implementation could still delegate to the other parser methods so it isn't to difficult to implement.
Yes, that's true. As I asked in other mail, I want to understand object allocation angle.

* We have a JIRA issue, that moves the cursor to certain place and creates a corresponding

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
public <T extends JsonValue> T getJsonValue(Class<T> clazz)

I like the option to alternate between streaming and dom-based parsing, but I would prefer distinct methods instead of one taking a Class parameter.
Why do you prefer separate methods ?

Maybe a better alternative for this usecase would be to extend JsonReader so it could be constructed from a JsonParser and allow reading of a partial stream.
That seems like good alternative. Your suggestion is something like the following:

JsonReader impl does this behind the scenes for the *full* stream. If this is not a common use case, then we can defer it.


[jsr353-experts] Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[jsr353-experts] Re: Remaining work in JsonParser

Jörn Horstmann 11/21/2012

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

Jitendra Kotamraju 11/21/2012

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

Jörn Horstmann 11/21/2012

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

Jitendra Kotamraju 11/26/2012
Please Confirm