[JSON_PROCESSING_SPEC-55] Remove JsonNumber.NumberType Created: 12/Feb/13  Updated: 12/Feb/13  Resolved: 12/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The discussion is at:
http://java.net/projects/json-processing-spec/lists/users/archive/2013-02/message/25



 Comments   
Comment by jitu [ 12/Feb/13 ]

Resolved as suggested in the discussion.





[JSON_PROCESSING_SPEC-54] Shorten getter method names; make chained getters read well when used together Created: 06/Feb/13  Updated: 10/Feb/13  Resolved: 10/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jfuerth Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The idea here is to make the following two changes, which work well together:

1. Remove 'value' from most getter names
2. Use the same method naming convention on JsonNumber as is used on java.lang.Number

The result is that repetitive-looking use cases like jsonObject.getNumberValue("num").getDoubleValue() turn into this non-repetitive arrangement: jsonObject.getNumber("num").doubleValue().

This suggestion, along with JSON_PROCESSING_SPEC-53, has been implemented here:

https://github.com/jfuerth/javax-json/commit/shorter-method-names



 Comments   
Comment by jitu [ 08/Feb/13 ]
  • Your changes have this : JsonParser#getInt(), JsonNumber#intValue(), JsonObject#getInt()

Should we use one scheme here: getInt() even in JsonNumber ? Then, s/getIntValueExact()/getIntExact()

Comment by jfuerth [ 09/Feb/13 ]

Good point. I thought about that too when I was making the method name changes.

The conclusion I arrived at was that JsonParser#getInt() makes somewhat more sense than JsonParser#intValue(). It matches JsonArray#getInt(int) and JsonObject#getInt(String). Only JsonNumber differs, and for these two reasons:

1. JsonNumber serves a similar purpose to java.lang.Number, and to me this is a strong case for staying with the familiar/expected naming scheme
2. When the JsonObject or JsonArray getter method names match the JsonNumber getter method name, chained calls like jsonObject.getNumber("key").getDouble() don't read as well as jsonObject.getNumber("key").doubleValue().

So my preference is still to stay with getXXX() method names across the whole javax.json API, but go with the very well established java.lang.Number method names on JsonNumber.

Comment by jitu [ 10/Feb/13 ]

Fixing it as suggested.





[JSON_PROCESSING_SPEC-53] Replace generic get methods in JsonArray & JsonObject with specific getters for object, array & number Created: 04/Feb/13  Updated: 10/Feb/13  Due: 08/Feb/13  Resolved: 10/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jfuerth Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Example of how this change affects a typical task such as pulling a numeric value out of a nested object:

Given a JSON data structure:

    {
        "id": 1234,
        "location": {
            "lat": 39.12333432,
            "long": -79.12344534
        }
    }

fetch the latitude from the nested "location" object.

BEFORE:

    JsonObject jo = ...;
    double lat = jo.get("location", JsonObject.class).get("lat", JsonNumber.class).getDoubleValue();

AFTER:

    JsonObject jo = ...;
    double lat = jo.getObject("location").getNumber("lat").doubleValue();

I've implemented this together with shortening of getter names (drop 'Value' from getter method names; adjusted JsonNumber to use the familiar java.lang.Number method naming convention)

You can play with it by pulling from here:

https://github.com/jfuerth/javax-json/commit/c88ec370a78154fa348758b9edbf022cf746d301



 Comments   
Comment by jitu [ 06/Feb/13 ]

I think JsonNumber names should be in a separate issue. We have the same names in other places, for e.g JsonParser#getIntValue()

Comment by jfuerth [ 06/Feb/13 ]

Oh, good catch! I thought I had found all of them. I'll open a separate issue.

Comment by jfuerth [ 06/Feb/13 ]

I removed 'Value' from the method names in JsonParser. The commit is available for review on the same branch at:

https://github.com/jfuerth/javax-json/commit/shorter-method-names

Comment by jitu [ 09/Feb/13 ]
  • You noted earlier, one thing unsettling is getObject/getArray/getNumber return JsonXXX, where as getString return String
  • Should we use getJsonObject/getJsonArray etc? It is bit long.
double lat = jo.get("location", JsonObject.class).get("lat", JsonNumber.class).getDoubleValue();

would be

double lat = jo.getJsonObject("location").getJsonNumber("lat").getDouble();
  • Since there are accessor methods for string, int (perhaps the common cases), should we just add array and object accessor methods.
Comment by jfuerth [ 09/Feb/13 ]

That sounds like a reasonable solution to me. Adding "Json" to the names of methods that return JsonValues eliminates the potential confusion.

Closely related issue:

In the change I made for review, I eliminated the JsonObject#get(String,Class) and JsonArray#get(int,Class). This means that it's no longer possible to retrieve a JsonString instance from an object or an array (you can only get the java.lang.String that the JsonString wraps). I didn't add a special method for obtaining the JsonString mostly because the getString() that returns java.lang.String was in the way. It doesn't seem like a big problem to me.

I can only see one potential use case for getting the JsonString wrapper held by a JsonObject or JsonArray: when copying a bunch of string values from a JsonObject to a JsonObjectBuilder, passing the unwrapped strings to the builder will require new JsonString wrapper instances to be created, whereas this could be avoided by passing the JsonString wrapper that the JsonObject was already using. The same does not go for arrays, because we can use JsonArray#asList(JsonString.class) to get at the wrappers.

What do you think? If we rename getObject -> getJsonObject, getArray -> getJsonArray(), getNumber() -> getJsonNumber(), should we also add a getJsonString()?

Comment by jitu [ 09/Feb/13 ]

I was planning to add a method for JsonString. But anyway, developers can always use get(string/index) and cast it.
I will do the changes and you can take a look at it.

Comment by jitu [ 10/Feb/13 ]

Removed
getValue(..., ...)

Added
JsonArray getJsonArray(...)
JsonObject getJsonObject(...)
JsonNumber getJsonNumber(...)
JsonString getJsonString(...)
boolean isNull(...)





[JSON_PROCESSING_SPEC-52] Make parsing location available to application code Created: 04/Feb/13  Updated: 08/Feb/13  Due: 08/Feb/13  Resolved: 08/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jfuerth Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The public review draft of the javax.json API does not make the parse location available to application code. Several members of the Toronto JUG indicated that this would be critically important to their adoption of the API.

It was suggested to create a Location type, and make location information available on request from JsonParser.getLocation(), and as a property of JsonParsingException.

Jitu pointed out that this was previously discussed on the mailing list. Here is that thread: http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/61



 Comments   
Comment by jitu [ 05/Feb/13 ]

StAX had Location, but all the information is optional as per javadoc.

Are there any real usecases for JsonParser.getLocation() ?

One proposal could be to add only to JsonParsingException (not for JsonParser):

interface JsonLocation

{ int getLineNumber(); int getColumnNumber(); int getStreamOffset(); }

-------
JsonParsingException(String message, JsonLocation location)
JsonParsingException(String message, Throwable cause, JsonLocation location)
JsonLocation getLocation()

Comment by jfuerth [ 05/Feb/13 ]

The JsonLocation interface you've proposed looks good.

I actually did ask one of the people who brought this up if it would be sufficient to put location information on the parsing exception only. He said no; he uses location information during his streaming XML parse, even when there are no syntax errors in the XML.

I don't know exactly what his use case is, but I can certainly imagine creating a system that throws an error when the data is semantically wrong. For example:

{ "id": 1234, "firstName": "Alice", "lastName": [1, 2, 3] }

although the above is a structurally valid JSON message, an application would likely want to reject it because lastName should be a string, but we were given an array. The application's own error message would be much better if it could include location information.

One final thought: unfortunately, we'll have to make location information optional too: when we are streaming a tree of JsonValues through JsonParser, there won't be an underlying character-oriented stream to calculate a line and column number from.

We could still require implementations to provide location information when the underlying data is coming from a string.

Comment by jitu [ 08/Feb/13 ]

Added JsonLocation as discussed





[JSON_PROCESSING_SPEC-51] JsonNumber equals()/hashCode() semantics Created: 01/Feb/13  Updated: 12/Feb/13  Due: 07/Feb/13  Resolved: 12/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The discussion is at http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/88

Instead of using BigDecimal.equals(), Jonathan suggesting to use BigDecimal.compareTo().






[JSON_PROCESSING_SPEC-50] Error in JavaDoc for JSONObjectBuilder Created: 31/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: srivastava.apoorvkumar Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JavaDoc has a sample JSONString

{
"firstName": "John", "lastName": "Smith", "age": 25,
"address" :

{ "streetAddress", "21 2nd Street", "city", "New York", "state", "NY", "postalCode", "10021" }

,
"phoneNumber": [

{ "type": "home", "number": "212 555-1234" }

,

{ "type": "fax", "number": "646 555-4567" }

]
}

Here the the value for key "address" is erroneous. It should either be an array or it should be converted in list of json key value pair using ' : ' .



 Comments   
Comment by jitu [ 31/Jan/13 ]

Fixing the typo as indicated in the issue

------------
[master 982aeae] JSON_PROCESSING_SPEC-50 Fixing typo in JSON text





[JSON_PROCESSING_SPEC-49] Rename JsonString#getValue() to getStringValue() Created: 25/Jan/13  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It has two methods to get string data. getStringValue()/asString() would be more appropriate.



 Comments   
Comment by jitu [ 04/Feb/13 ]

Fixed as suggested





[JSON_PROCESSING_SPEC-48] Add accessor method to consume same type of objects in JsonArray Created: 25/Jan/13  Updated: 08/Feb/13  Due: 07/Feb/13  Resolved: 08/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Jonathan suggests that API add the following method to consume same type of objects in JsonArray

<T extends JsonValue> List<T> JsonArray#getValuesAs(Class<T>) or
<T extends JsonValue> Iterable<T> JsonArray#getValuesAs(Class<T>)

see the discussion

http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/0



 Comments   
Comment by jitu [ 08/Feb/13 ]

Added an accessor method that provides a list view of the specified type





[JSON_PROCESSING_SPEC-47] Remove exception constructors Created: 25/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Feedback from exception handling section in http://crazyjavahacking.org/jsonProcessingReview.pdf

Remove
JsonException()
JsonException(Throwable)

JsonGenerationException()
JsonGenerationException(Throwable)

JsonParsingException()
JsonParsingException(Throwable)



 Comments   
Comment by jitu [ 30/Jan/13 ]

Fixing this as suggested in the issue.





[JSON_PROCESSING_SPEC-46] Missing constructor JsonReader(InputStream, Map<String, ?> Created: 24/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Bug Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JsonReader(InputStream, Map<String, ?>) constructor is missing. I think we should add that.



 Comments   
Comment by jitu [ 24/Jan/13 ]

Added the missing constructor





[JSON_PROCESSING_SPEC-45] JsonObject/JsonArray accessor methods that take default values Created: 11/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the discussion
http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/120
http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/17



 Comments   
Comment by jitu [ 31/Jan/13 ]

Added the methods that take default values in both JsonArray and JsonObject





[JSON_PROCESSING_SPEC-44] Replace JsonFeature/JsonConfiguration with Properties Created: 11/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Brian Goetz's feedback

"I think JsonFeature is a mistake. You'll be playing whack-a-mole forever, and the spec will lag behind implementations with respect to features. Trying to capture all these strongly typed in the API is a recipe for chasing our tail."



 Comments   
Comment by jitu [ 24/Jan/13 ]

Removed JsonConfiguration/JsonFeature

Added Map<String, ?> as configuration as per discussion.





[JSON_PROCESSING_SPEC-43] JsonObject#getIntValue() javadoc says it would return null Created: 07/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Bug Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JsonObject#getIntValue() javadoc says it would return null if there is no mapping. It should throw NPE if there is no mapping. Similarly, getStringValue() should throw NPE if there is no mapping.



 Comments   
Comment by jitu [ 30/Jan/13 ]

Resolving the issue as indicated in the description.





[JSON_PROCESSING_SPEC-42] Add overview to the javadoc Created: 07/Jan/13  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add a overview to javadoc so that the main page (http://json-processing-spec.java.net/nonav/releases/1.0/pr-draft/javadocs/index.html) will have scope and high-level description etc.



 Comments   
Comment by jitu [ 04/Feb/13 ]

Added the javadoc overview page





[JSON_PROCESSING_SPEC-40] JsonBuilder and JsonReader should be interfaces Created: 11/Dec/12  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jhorstmann Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current design limits possible performance improvements that could be obtained by custom parser implementations. A cleaner design would let the implementation provide both parser and object model implementations that are better integrated and higher performing.

If we implement http://java.net/jira/browse/JSON_PROCESSING_SPEC-9 a json structure could consist of a mix between implementations from the api package and implementation defined classes.

Builders would be created by static methods of the Json class or a JsonBuilderFactory created via the Json class.
JsonReader would require a JsonReaderFactory with similar methods to JsonParserFactory.

Discussion at http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/9 and http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/54



 Comments   
Comment by jitu [ 12/Dec/12 ]

Since JsonParser/JsonGenerator are already used by JsonReader/JsonGenerator, most of the performance improvements are available from a provider. Perhpas, the remaining improvements for JsonString/JsonNumber impl may not be much.

The high-level API should more usable than the low-level API, i.e new JsonArrayBuilder() etc is more user friendly.

Otherwise, a possible approach is to introduce
JsonReaderFactory, JsonWriterFactory, JsonBuilderFactory, and all possible methods on Json. That seem bit heavy-weight to me and not justify the performance benefits.

Comment by wenshao [ 13/Dec/12 ]

i can not understand why not be interfaces?

not just these two, should be interfaces include following:
JsonReader
JsonWriter
JsonArrayBuilder
JsonObjectBuilder

Comment by jhorstmann [ 07/Jan/13 ]

The current design, with only JsonParser as an implementation provided class, also seems to have performance problems of its own due to repeated ServiceLoader lookup. With JsonReader as an interface and a threadsafe JsonReaderFactory these lookups can be avoided.

Discussion at http://java.net/projects/json-processing-spec/lists/users/archive/2013-01/message/2

Comment by jitu [ 09/Jan/13 ]

One suggestion was to cache the provider so that there won't be service lookup costs for each JsonReader/JsonWriter. The cache strategy that is suggested is:
"The cache should be a ThreadLocal, and the cached value should include
a reference to the class loader that was used to look up the provider,
presumably the thread-context class loader. Use the cached provider only
when the saved class loader matches the one that you'd use if you were
going to look it up again."

Comment by jitu [ 04/Feb/13 ]

Made JsonReader, JsonWriter, JsonArrayWriter, JsonObjectWriter as interfaces.
Added JsonReaderFactor, JsonWriterFactory, JsonBuilderFactory interfaces to create these objects.

Added methods to create these objects as well as the factory classes.





[JSON_PROCESSING_SPEC-30] Exposing Location in JsonParser and JsonParsingException Created: 03/Dec/12  Updated: 05/Feb/13  Resolved: 05/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Location discussion is at
http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/70






Generated at Mon Jul 06 01:42:39 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.