Skip to main content

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

  • From: Jitendra Kotamraju < >
  • To:
  • Subject: [json-processing-spec users] [jsr353-experts] Re: Re: Re: Remaining work in JsonParser
  • Date: Mon, 26 Nov 2012 13:27:04 -0800
  • List-id: <jsr353-experts.json-processing-spec.java.net>

On 11/21/2012 03:13 PM, Jörn Horstmann wrote:
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
iterator.

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`.
OK, I will replace iterator() with hasNext/next methods. I will see if get any feedback on this.

* 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?
It may require a revision during that time. That revision could be a MR (maintenance release) and has a much shorter life cycle. We need a few frameworks to layer on the current functionality and see what is really required.

* 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
*/
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.
Good point. So, only getJsonArray(), getJsonObject() (or different names as Tatu suggested) are really required methods. But building them using the builder is not that difficult for this usecase. May be, we can defer it.

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#readArray(JsonParser)

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.
I don't think creating multiple JsonReader objects would be a problem. I just wonder whether we should add new constructors to JsonReader that take parser. We also need to define that JsonReader#close() doesn't close the parser in this case which is different from the other input sources that JsonReader is taking. So, I think it doesn't fit well there.

Jitu

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.

Jörn



[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