Skip to main content

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

  • From: Jörn Horstmann < >
  • To:
  • Subject: [jsr353-experts] Re: [json-processing-spec users] Re: Remaining work in JsonParser
  • Date: Thu, 22 Nov 2012 00:13:37 +0100

On 11/21/2012 09:26 PM, Jitendra Kotamraju wrote:
On 11/21/2012 01:03 AM, Jörn Horstmann wrote:
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

At the moment JsonParser looks more like an Iterable than an iterator, even though it does not implement Iterable. We could add methods like `hasMoreEvents` and `nextEvent` directly to JsonParser and remove the `iterator` method. But these are just names, and since these two methods would behave like the methods from Iterator, which are short and familiar to developers, I think we should just name them `hasNext` and `next`.

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

I'm okay with first providing a minimal version. As standards are moving rather slowly, do you think we will already need a revision of this spec when a Json-Binding JSR starts off?

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

I think with a getJsonValue(Class) method, its not exactly clear what the allowed parameters are. For example, can I call it with org.glassfish.jsonapi.JsonNumberImpl.class or my own class implementing any of these interfaces? Probably not, but the compiler will accept such code.

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

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

I was thinking of additional constructors in JsonReader. Since it already contains a JsonParser instance it would be strange to pass another as a parameter. A downside would be that you'd have to create a new JsonReader per object or array to read, but JsonReader is a pretty light-weight class.

We should probably add both new constructors to JsonReader and get methods to JsonParser. Since JsonReader is part of the api package, it would not know about any specialized JsonValue implementations that a JsonParser impl could return. It might still be useful to create a standard dom tree from any JsonParser but defer the get-methods to a later version.


[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