[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-56] Use long instead of int for JsonLocation's line no, column no, stream offset Created: 11/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

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

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   

See the discussion thread
http://java.net/projects/json-processing-spec/lists/users/archive/2013-03/message/8






[JSON_PROCESSING_SPEC-57] NPE for null name or null key in object builder Created: 12/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

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

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   

JsonObjectBuilder and JsonArrayBuilder don't allow null for a name or a value. Add it to the javadoc.






[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-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-8] Factory to create JsonParser, JsonGenerator instances Created: 13/Jun/12  Updated: 15/Oct/12  Resolved: 15/Oct/12

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

Type: New Feature 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 following user thread has all the discussion:
http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/41



 Comments   
Comment by jitu [ 15/Oct/12 ]

Factory classes are already added





[JSON_PROCESSING_SPEC-7] Don't extend JsonArray with Iterable<JsonValue> Created: 13/Jun/12  Updated: 25/Jun/12  Resolved: 25/Jun/12

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

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   

May be JsonArray shouldn't extend with Iterable<JsonValue>. By extending, it is committing to the particular type and hard to change later. Also, collections are going through major changes w.r.t lambdafication. There is already a method to get List<JsonValue> which is Iterable<JsonValue> and if required we add an additional method.



 Comments   
Comment by jitu [ 25/Jun/12 ]

Resolving it: JsonArray doesn't extend Iterable<JsonValue> anymore





[JSON_PROCESSING_SPEC-6] Better name for JsonNumber#getNumberType() Created: 13/Jun/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

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

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


 Description   

Need a better name for JsonNumber#getNumberType(). The method is really returns just the smallest numeric type that can be used with that value.



 Comments   
Comment by jitu [ 14/Dec/12 ]

Got resolved with JSON_PROCESSING_SPEC-41. NumberType just gives INTEGER or DECIMAL





[JSON_PROCESSING_SPEC-4] Need a method to get the number of values in JsonArray Created: 23/May/12  Updated: 12/Jun/12  Resolved: 12/Jun/12

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

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: "If there is going to be indexed access there needs to be a way to
obtain the length in JsonArray"



 Comments   
Comment by jitu [ 23/May/12 ]

Proposed solution is to add the following method to JsonArray that gives the number of values in a JSON array

int size()

Comment by illsleydc [ 26/May/12 ]

Makes sense to me.





[JSON_PROCESSING_SPEC-3] addArray methods in Builder Created: 21/May/12  Updated: 18/Jun/12  Resolved: 18/Jun/12

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

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 on addArray methods: "API already has beginArray() for starting a new array, better to turn this into addAll(Iterable<JsonValue>) which would add all the elements of the iterable at the current point. That way addAll() can do double-duty both to bulk-add into the currently built array, or you can do .beginArray().addAll(iterable).endArray() to add a nested array."



 Comments   
Comment by jitu [ 21/May/12 ]

Proposed changes are:

Remove
JsonArrayBuilder#addArray(Iterable<JsonValue>)
JsonObjectBuilder#addArray(String, Iterable<JsonValue>)

and add
JsonArrayBuilder#addAll(Iterable<JsonValue>)

Comment by illsleydc [ 26/May/12 ]

I definitely agree with the need for an addAll to JsonArrayBuilder, but I think it's worth exploring further and adding a few... (I don't know where a developer would normally be getting the Iterable<JsonValue> from?)

addAll(Iterable<String>), addAll(Iterable<Integer>), addAll(Iterable<Double>)

The obvious inefficiency here is for people with int[] or double[]. For them, addAll(int...) etc would be better. That could get to be a lot of methods, but with consistent naming, it might not feel too overwhelming.

Comment by jitu [ 14/Jun/12 ]

> I definitely agree with the need for an addAll to JsonArrayBuilder, but I think it's worth exploring further and adding a few... (I don't know where a developer would normally be getting the Iterable<JsonValue> from?)

The developer may get Iterable<JsonValue> from an existing JsonArray, say JsonArray#getValues().

>addAll(Iterable<String>), addAll(Iterable<Integer>), addAll(Iterable<Double>)
>The obvious inefficiency here is for people with int[] or double[]. For them, addAll(int...) etc would be better. That could get to be a lot of methods, but with consistent naming, it might not feel too overwhelming.

We already have methods to add one JsonValue, int, String etc. Perhaps, we just remove the current addArray() methods and not add any new addAll methods. A developer can add them using the existing methods in a loop. If the addAll methods really needed, we can add them later.

Comment by jitu [ 18/Jun/12 ]

Removing the addArray methods on the builders.





[JSON_PROCESSING_SPEC-17] JsonParser shouldn't extend Iterable Created: 24/Oct/12  Updated: 03/Dec/12  Resolved: 24/Oct/12

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

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   

http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/72



 Comments   
Comment by jitu [ 24/Oct/12 ]

Checked with SE team regarding Iterable. Here is a comment

"While the specifications do not require that an Iterable can be iterated repeatedly/consistently, many users expect this and are likely to be confused if they cannot.

If you do not intend iterator() to return a fresh "rewound" view every time, then you should probably follow the convention set by Socket.getInputStream(), which returns the same stream on every call.

You definitely don't want to implement Iterator; a parser is-not-a Iterator. One option would be to have an iterator() method but not implement Iterable, where the iterator() method was spec'ed to behave as above – just return the same Iterator object every time. All you lose there is the foreach loop support – no big deal.

Overall I think you sow more confusion than benefit by implementing Iterable.

When you get to EE 8 you can implement Streamable too!"

Based on this, added iterator() method.





[JSON_PROCESSING_SPEC-15] Use Charset instead of string in methods Created: 23/Oct/12  Updated: 29/Oct/12  Resolved: 24/Oct/12

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

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   

For e.g.:
s/JsonReader(InputStream in, String encoding)/JsonReader(InputStream,
CharSet)
JDK 7 defined constants for standard charsets in StandardCharsets. For e.g
StandardCharsets.UTF_8
Applications take advantage of those constants when they use JDK 7. That
also means that API doesn't have to specify
of wrapping UnsupportedEncodingException in many places. Infact, it seems to
be that some places UnsupportedCharsetException/IllegalCharsetNameException
would be more appropriate than UnsupportedEncodingException.



 Comments   
Comment by jitu [ 24/Oct/12 ]

Added Charset instead of String while creating JsonParser/JsonGenerator/JsonReader/JsonWriter.





[JSON_PROCESSING_SPEC-13] JsonParser/JsonGenerator/JsonReader/JsonWriter close() need to close underlying source Created: 16/Oct/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

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

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   

close() need to call close on the underlying source as that seems like more common usage. So make this as default. Some more discussion is at:
http://java.net/projects/json-processing-spec/lists/users/archive/2012-10/message/11



 Comments   
Comment by jitu [ 27/Nov/12 ]

Javadoc is updated to close the underlying source by default.





[JSON_PROCESSING_SPEC-41] Remove NumberType.LONG and rename NumberType.BigDecimal Created: 11/Dec/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

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

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   

NumberType would be less confusing if it just stated the distinction whether a number has a fractional part.

A NumberType of INTEGER would guarantee that calling getBigIntegerValue does not throw an ArithmeticException. The NumberType would be independent of the actual magnitude of the number, thus calling getIntValueExact might still throw an Exception if the number is smaller than Integer.MIN_VALUE of larger than Integer.MAX_VALUE.

The current NumberType BIG_DECIMAL should be renamed to just DECIMAL or REAL (see http://en.wikipedia.org/wiki/Real_number) and would indicate that the number has a fractional part and calling get(Int|Long|BigInteger)ValueExact might throw an ArithmeticException.

The algorithm for distinguishing these two types should be based on whether BigDecimal#scale() is 0.

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



 Comments   
Comment by jhorstmann [ 11/Dec/12 ]

On a Jave ME profile of this JSON API, the methods getBigIntegerValue(Exact) and getBigDecimalValue would be excluded, NumberType should be INTEGER if the number can be exactly represented as a long, which is the largest integral type on such platforms.

Comment by jitu [ 11/Dec/12 ]

The current number type is the minimum holding number type. For 1.23e2, it gives INT.

This proposal is primarily removing "minimum holding" number type. So API doesn't provide a way if the integral number fits into int, long, BigInteger, and it becomes an application responsibility.

If applications don't require to know about this minimum holding number type, then I am fine with the proposal. I will see if there any comments internally.

Comment by keilw [ 12/Dec/12 ]

>The algorithm for distinguishing these two types should be based on whether >BigDecimal#scale() is 0.

What would it be on ME, as BigDecimal and BigInteger would not be there?

Aside from that, I fully agree with renaming BIG_DECIMAL to something like DECIMAL, REAL or FLOATING, which covers all numbers with decimal value.

And keep INTEGER or rename INT, ideally dropping the LONG.

An alternative could again be the JSON spec which knows
int

  • digit
  • digit1-9 digits
    • digit
    • digit1-9 digits

frac

  • . digits

exp

  • e digits

see http://json.org/

If there are sufficient algorithms to tell FRAC (which is quite similar to FLOATING or DECIMAL) from EXP, this may be closest to JSON design.

Werner

Comment by jitu [ 13/Dec/12 ]

ME could use a similar algo what scale() is doing to determine if the number has a fractional part or not.

I am thinking of rolling the following:

    /**
     * JSON number type that is used to find out if a number is numerically
     * integer or a decimal.
     */
    enum NumberType {
        /**
         * Represents a number that is numerically integer.
         * The value can be accessed as int, long, or BigInteger using
         * different JsonNumber accessor methods.
         */
        INTEGER,

        /**
         * Represents a number that is numerically decimal. The value can
         * be accessed as double, or BigDecimal using different JsonNumber
         * accessor methods.
         */
        DECIMAL
    }

    /**
     * Returns a JSON number type for this number.
     * A {@link BigDecimal} may be used to store the numeric value internally
     * and the semantics of this method is defined using
     * {@link BigDecimal#scale()}.
     * If the scale of a value is zero, then its number type is
     * {@link NumberType#INTEGER INTEGER} else {@link NumberType#DECIMAL DECIMAL}.
     *
     * <p>
     * The number type can be used to invoke appropriate accessor methods to get
     * numeric value for the number.
     * <p>
     * <b>For example:</b>
     * <code>
     * <pre>
     * switch(getNumberType()) {
     *     case INTEGER :
     *         long l = getLongValue(); break;
     *     case DECIMAL :
     *         BigDecimal bd = getBigDecimalValue(); break;
     * }
     * </pre>
     * </code>
     *
     * @return a number type
     */
    NumberType getNumberType();
Comment by jhorstmann [ 13/Dec/12 ]

A ME profile would probably store the number in a double, which has no concept similar to BigDecimal#scale(). It could return type INTEGER if getDoubleValue() == Math.floor(getDoubleValue());, but this would return different results than an implementation based on BigDecimal for numbers like "1.0".

The equivalent code with BigDecimal would be:

try {
    bd.setScale(0, RoundingMode.UNNECESSARY);
    return NumberType.INTEGER;
} catch (ArithmeticException ex) {
    return NumberType.DECIMAL;
}

If we can not decide on the correct semantics, then it would probably be better to remove the NumberType distinction completely or defer it to a future version.

Comment by jitu [ 13/Dec/12 ]

Let me commit the proposal in this issue. I don't think we need to define what ME is going to do here now. Anyway, ME needs to define semantics for other methods like equals(), hashCode() etc.

Comment by jitu [ 14/Dec/12 ]

Resolving with the proposal in this issue





[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-39] JSON API renaming: s/JsonArray/JsonList and s/JsonObject/JsonMap Created: 11/Dec/12  Updated: 13/Dec/12  Resolved: 13/Dec/12

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

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   

Mark Reinhold's feedback
-------------------------
Looking at this API in depth for the first time, I kept getting confused
by the name "JsonObject".

In Java terms, what JSON calls an "Object" is just a map, from strings to
JSON values. Java already uses "Object" as the unifying supertype of all
types, so I'd expect "JsonObject" to unify (some set of) JSON-specific
value types.

This suggests a renaming along these lines:

JsonObject --> JsonMap
JsonObjectBuilder --> JsonMapBuilder
JsonStructure --> JsonObject

I think Java developers would find this more natural, since most will
never read the actual JSON specification.

Remember that this API is for Java developers, not readers of the JSON
specification.
-------------



 Comments   
Comment by jitu [ 11/Dec/12 ]

I received the same feedback from Brian Goetz earlier. But some libraries are already using JsonObject and JsonArray, so we continued that naming. But this API is for Java developers, so we should follow what is suggested by Mark and Brian.

This would also mean we need to change in other places

JsonArray --> JsonList
JsonArrayBuilder --> JsonListBuilder

  • JsonReader and JsonWriter changes
    s/readArray/readList
    s/readObject/readMap

s/writeArray/writeList
s/writeObject/writeMap

  • JsonGenerator
    s/writeStartArray/writeStartList
    s/writeStartObject/writeStartMap
  • We have events (like START_ARRAY etc) in the JsonParser. Those need to be changed to START_LIST etc
  • ValueType has ARRAY and OBJECT, those will be changed to LIST and MAP.
Comment by jitu [ 13/Dec/12 ]

http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/75

Based on the discussion, resolving this one with no action.





[JSON_PROCESSING_SPEC-35] Add ability to read/writer numeric types as String Created: 07/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

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


 Description   

Allow Strings to be written to and read from JSON numeric types.

Relevant Use Cases:

  • Ensure I can get a value represented as 1.23e10 (JSON allows this representation)
  • If I have a form that is being using to collection data, this data can be written to JSON without first having to convert it to a numeric type.
  • Make it easier to port data from XML to JSON, again no need to first convert it to a numeric type.


 Comments   
Comment by jitu [ 07/Dec/12 ]

Suggest the following methods in JsonGenerator.

JsonGenerator writeNumber(String name, String number)
JsonGenerator writeNumber(String number)

The number string value needs to be validated as per JSON grammar.

Comment by jitu [ 12/Dec/12 ]

http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/46

Based on the discussion, resolving with no action.





[JSON_PROCESSING_SPEC-18] Add convenient accessor methods for string, int values on JsonArray and JsonObject Created: 24/Oct/12  Updated: 03/Dec/12  Resolved: 25/Oct/12

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

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   

Instead of calling JsonArray.getValue(0, JsonString.class).getValue(), provide
a convenient method JsonArray.getStringValue(0). Similarly they should be
added for JsonObject as well.



 Comments   
Comment by jitu [ 25/Oct/12 ]

Adding the following methods:
JsonArray.java
+ public String getStringValue(int index);
+ public int getIntValue(int index);

JsonObject.java
+ public String getStringValue(String name);
+ public int getIntValue(String name);





[JSON_PROCESSING_SPEC-11] Flushable for JsonGenerator Created: 15/Oct/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

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

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   

See the thread
http://java.net/projects/json-processing-spec/lists/users/archive/2012-10/message/17



 Comments   
Comment by jitu [ 27/Nov/12 ]

Reworked JsonGenerator and it implements Flushable now.





[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






[JSON_PROCESSING_SPEC-59] JavaDoc problems when building with JDK 8 Created: 18/Jul/13  Updated: 06/May/14  Resolved: 06/May/14

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

Type: Bug Priority: Minor
Reporter: heliofrota Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

gnu-linux manjaro distribution x86 jdk8-b7


Tags: adoptajsr

 Description   

Build error due javadoc problems when building with jdk8 b97

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar (attach-javadocs) on project javax.json-api: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: warning - Error fetching URL: http://docs.oracle.com/javase/6/docs/api
[ERROR] /home/hf/Desktop/cejug/adopt_a_jsr/jsonp~git/api/src/main/java/javax/json/JsonArray.java:177: warning: no @param for <T>
[ERROR] <T extends JsonValue> List<T> getValuesAs(Class<T> clazz);
[ERROR] ^
[ERROR] /home/hf/Desktop/cejug/adopt_a_jsr/jsonp~git/api/src/main/java/javax/json/JsonArray.java:201: warning: no @param for defaultValue
[ERROR] String getString(int index, String defaultValue);
[ERROR] ^

Full logs on JSR mailing list.



 Comments   
Comment by heliofrota [ 23/Jul/13 ]

Maybe this is issue from maven javadoc plugin and this line:
[ERROR] Exit code: 1 - javadoc: warning - Error fetching URL: http://docs.oracle.com/javase/6/docs/api

I going to investigate this.

Comment by kchung [ 06/May/14 ]

Fixed.





Generated at Sat May 23 04:47:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.