Skip to main content

[jsr353-experts] Re: Remaining work in JsonParser

  • From: Jörn Horstmann < >
  • To:
  • Subject: [jsr353-experts] Re: Remaining work in JsonParser
  • Date: Wed, 21 Nov 2012 10:03:35 +0100

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.

* 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 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.

* 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.

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.


[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