[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-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-38] Extend JsonArray with List<JsonValue> and JsonObject with Map<String, JsonValue> Created: 09/Dec/12  Updated: 11/Dec/12  Resolved: 11/Dec/12

Status: Closed
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   

Mark Reinhold's feedback:
----------
Is there a reason that JsonObject
(current name) doesn't implement java.util.Map<String,JsonValue>
directly? It seems awkward to have to invoke a getValues() method
in order to get an actual Map.
------------
My hesistation is Map has mutable methods. He still considers there
is value by implementing these collections. He says:
------------
The mutating methods in the Map interface are all optional; you can just
have them throw UnsupportedOperationException.

Along similar lines, JsonList should implement java.util.List<JsonValue>.

These two changes will make it much easier to leverage the existing
collections framework as well as all the Lambda goodness coming in SE 8.
----------------



 Comments   
Comment by jitu [ 11/Dec/12 ]

Fixing it as specified in the issue: JsonArray extends List<JsonValue> and JsonObject extends Map<String, JsonValue>





[JSON_PROCESSING_SPEC-37] Json has too many methods Created: 08/Dec/12  Updated: 08/Dec/12  Resolved: 08/Dec/12

Status: Closed
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   

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

Keep only commonly created parser, generator methods. Other variations can be got from their factories.



 Comments   
Comment by jitu [ 08/Dec/12 ]

Fixing it as suggested in the thread
http://java.net/projects/json-processing-spec/lists/users/archive/2012-12/message/31





[JSON_PROCESSING_SPEC-36] JSON builder improvements Created: 07/Dec/12  Updated: 10/Dec/12  Resolved: 10/Dec/12

Status: Closed
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   

Feedback from Mark Reinhold
--------------------------------------
The EDR javadoc for JsonObject contains this builder-pattern example:

    JsonObject object = new JsonBuilder()
        .beginObject()
            .add("firstName", "John")
            .add("lastName", "Smith")
            .add("age", 25)
            .beginObject("address")
                .add("streetAddress", "21 2nd Street")
                .add("city", "New York")
                .add("state", "NY")
                .add("postalCode", "10021")
            .endObject()
            .beginArray("phoneNumber")
                .beginObject()
                    .add("type", "home")
                    .add("number", "212 555-1234")
                .endObject()
                .beginObject()
                    .add("type", "home")
                    .add("number", "646 555-4567")
                .endObject()
            .endArray()
        .endObject()
    .build();

One problem with this style is that the structure of the object being
constructed is not reflected in the syntax of the expression. A reader
must visually scan for "begin" and "end" methods in order to understand
the resulting object structure, or even just to indent the code.

Here's a variant of the above example written against a (hypothetical)
alternative API:

    JsonObject value = new JsonObjectBuilder()
        .add("firstName", "John")
        .add("lastName", "Smith")
        .add("age", 25)
        .add("address", new JsonObjectBuilder()
             .add("streetAddress", "21 2nd Street")
             .add("city", "New York")
             .add("state", "NY")
             .add("postalCode", "10021"))
        .add("phoneNumber", new JsonArrayBuilder()
             .add(new JsonObjectBuilder()
                  .add("type", "home")
                  .add("number", "212 555-1234"))
             .add(new JsonObjectBuilder()
                  .add("type", "home")
                  .add("number", "646 555-4567")))
        .build();

Note how the structure of the resulting object is obvious from the
structure of the expression, which (by the way) is indented correctly
(at least by Emacs) without any manual effort at all. You also don't
need the "end" methods.

Have you considered a design that would support this style? I think
it's much more readable.
--------------------------



 Comments   
Comment by jitu [ 07/Dec/12 ]

The current design was used by JsonBuilder as well as JsonGenerator, and it is more suitable from streaming generation. Now JsonGenerator is moved to its own abstraction, this proposal is appealing.

Here are some observations:

  • proposal seems to be simpler
  • here one has to start with JsonObjectBuilder and JsonArrayBuilder. In the current design, one just starts with JsonBuilder always.
  • uses two classes, instead of all the other baggage like JsonBuildable, JsonBuilder
  • avoids the generics trick which end() method is doing.
  • end() is not required
  • The earlier design also works for generating JSON in a streaming fashion. Now(after EDR) JsonGenerator uses its own abstraction, so this seems more suitable now.
  • I think this is also guarantees compile-time safety to the building objects similar to the current one i.e one cannot add JSON array values in objects (name/value pairs)
  • I think we can still add existing JsonArray/JsonObject

I would like to incorporate the Marc's proposal.

Comment by jitu [ 10/Dec/12 ]

Incorporating the suggested proposal.





[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-34] Consistent inner class names : s/JsonValueType/ValueType s/JsonNumberType/NumberType Created: 06/Dec/12  Updated: 08/Dec/12  Resolved: 08/Dec/12

Status: Closed
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   

http://java.net/projects/json-processing-spec/lists/jsr353-experts/archive/2012-12/message/36



 Comments   
Comment by jitu [ 08/Dec/12 ]

Done the specified change





[JSON_PROCESSING_SPEC-33] Make Json class constructor private Created: 05/Dec/12  Updated: 05/Dec/12  Resolved: 05/Dec/12

Status: Closed
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   

http://java.net/projects/json-processing-spec/lists/jsr353-experts/archive/2012-12/message/24



 Comments   
Comment by jitu [ 05/Dec/12 ]

Making Json class constructor private





[JSON_PROCESSING_SPEC-28] JsonString#getChars() that return CharSequence Created: 30/Nov/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

Status: Closed
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   

JsonString#getChars() that returns a CharSequence would be useful so that a big string need not be created



 Comments   
Comment by jitu [ 30/Nov/12 ]

Added the method

/**

  • Returns the char sequence for the JSON String value
    *
  • @return a char sequence for JSON String value
    */
    CharSequence getChars();




[JSON_PROCESSING_SPEC-27] Remove JsonParser#iterator() method Created: 27/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Closed
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   

Remove JsonParser#iterator() method and replace with hasNext() and next(). The problem with iterator is not returning self-contained events. One has to go back forth between iterator and parser objects. One proposal was to use advance() (instead of hasNext()) and getEvent() (instead of next()), but most users preferred hasNext()/next().

Some of the discussion is at:
http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/63



 Comments   
Comment by jitu [ 03/Dec/12 ]

Replaced iterator() method with hasNext()/next() methods.





[JSON_PROCESSING_SPEC-26] Provide read() methods to return Map<String,Object> and List in JsonReader Created: 27/Nov/12  Updated: 09/Dec/12  Resolved: 09/Dec/12

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

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


 Description   

The JsonReader can have two additional read() methods to de-serialize a JSON object or array.

JsonReader {
Map<String,Object> readObjectAsMap( )
List readArrayAsList( )
}

Map<String,Object> --> JSON object
List --> JSON array
The element objects in the Map or List can be any valid Java-JSON types or a Map or a List.

This will avoid the need to convert a JsonObject or JsonArray to a Map<String,Object> or a List object respectively after de-serializing via JsonReader.



 Comments   
Comment by jitu [ 09/Dec/12 ]

Will consider JsonArray to implement List<JsonValue>
and JsonObject to implement Map<String, JsonValue>





[JSON_PROCESSING_SPEC-24] Provide write() methods for Map<String,Object> and List in JsonWriter Created: 27/Nov/12  Updated: 09/Dec/12  Resolved: 09/Dec/12

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

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


 Description   

The JsonWriter can have two additional write() methods to serialize a Map<String,Object> and a List.

JsonWriter {
write(Map<String,Object> jsonObject)
write(List jsonArray)
}

Map<String,Object> --> JSON object
List --> JSON array
The element objects in the Map or List can be any valid Java-JSON types or a Map or a List.

This will avoid the need to convert a Map<String,Object> or a List object to a JsonObject or JsonArray respectively before serializing via JsonWriter.



 Comments   
Comment by jitu [ 09/Dec/12 ]

Will consider JsonArray to implement List<JsonValue> and
JsonObject to implement Map<String, JsonValue>

Other than that we don't provide support any Object





[JSON_PROCESSING_SPEC-23] JsonBuilder method names:s/begin/start Created: 20/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Closed
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   

s/beginArray/startArray
s/beingObject/startObject
s/endObject/end
s/endArray/end

This would reflect JsonParser events. JsonGenerator also uses "writeStartXXX"



 Comments   
Comment by jitu [ 03/Dec/12 ]

changed method names





[JSON_PROCESSING_SPEC-21] Add toString() to JsonObject/JsonArray Created: 25/Oct/12  Updated: 09/Dec/12  Resolved: 09/Dec/12

Status: Closed
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   

toString() should give the JSON representation



 Comments   
Comment by jitu [ 25/Oct/12 ]

Adding JsonValue#toString() method

Comment by jitu [ 03/Dec/12 ]

Closing the issue

Comment by jitu [ 09/Dec/12 ]

Need to mark the Fix version

Comment by jitu [ 09/Dec/12 ]

Marking the fix version





[JSON_PROCESSING_SPEC-20] remove JsonValue Created: 25/Oct/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

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

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


 Description   

It is difficult to use.

JsonArray & JsonObject should direct support primitive type, include:

Byte, Short, Integer, Long, BigInteger, BigDecimal, Float, Double
Boolean, String
null

JsonArray & JsonObject should include pirimitive operation, like:
class JsonObject {
int getIntValue(String name, int defaultValue);
Integer getInt(String name);
long getLongValue(String name, int defaultValue);
Long getLong(String name);
... ...

JsonArray getJsonArray(String name);
JsonObject getJsonObject(String name);
}

class JsonArray {
int getIntValue(int index, int defaultValue);
Integer getInt(int index);
long getLongValue(int index, int defaultValue);
Long getLong(int index);
... ...

JsonArray getJsonArray(int index);
JsonObject getJsonObject(int index);
}



 Comments   
Comment by jitu [ 25/Oct/12 ]

I have already added few methods in JsonObject and JsonArray for common cases. They are convenience methods(still use JsonValue), see http://java.net/jira/browse/JSON_PROCESSING_SPEC-18

You are raising bigger question which is to not use JsonString, JsonNumber. Instead, use existing types.
There are few use cases:

  • For example, if the JSON string data is huge, we cannot map to String. But JsonString could be used (perhaps backed up by a file)
  • Number has two many types. And if a number needs to be represented as String, it would be a problem since string is used for JSON string.
  • Having a common type helps, but if it is too difficult to use, then we should consider again. Other option is to mix and match primitives and JsonValue types. But that would be too messy.

Let us take the discussion to users mailing list.

Comment by jitu [ 30/Nov/12 ]

There was quite a bit of discussion on the mailing list and also with JDK architects.

Closing this one without any fix.





[JSON_PROCESSING_SPEC-19] Add JsonParsingException, JsonGenerationException Created: 24/Oct/12  Updated: 05/Dec/12  Resolved: 05/Dec/12

Status: Closed
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   

The following thread has exception discussion
http://java.net/projects/json-processing-spec/lists/users/archive/2012-10/message/27



 Comments   
Comment by jitu [ 05/Dec/12 ]

Added JsonParsingException and JsonGenerationException as per discussion. They are used primarily to catch incorrect JSON while parsing and generating





[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-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-14] equals()/hashcCode() for object model Created: 19/Oct/12  Updated: 29/Nov/12  Resolved: 29/Nov/12

Status: Closed
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   

Define equals()/hashCode() semantics



 Comments   
Comment by jitu [ 29/Nov/12 ]

equals()/hashCode() is defined as follows:

JsonNumber

  • BigDecimal getBigDecimal(). BigDecimal is used for equals()/hashCode()

JsonObject

  • Map<String, JsonValue> getValues(). Map is used for equals()/hashCode()

JsonArray

  • List<JsonValue> getValues(). List is used for equals()/hashCode()

JsonString

  • String getString(). String is used for equals()/hashCode()

JsonTrue/JsonFalse/JsonNull

  • JsonValueType getValueType(). The corresponding enum is used for equals()/hashCode()




[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-12] JsonObjectBuilder should throw exception for duplicate keys Created: 16/Oct/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

Status: Closed
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   

JsonObjectBuilder should throw exception for duplicate keys while buiding JSON Objects



 Comments   
Comment by jitu [ 03/Dec/12 ]

Should we throw exception or overwrite the existing mapping ?

Comment by jitu [ 12/Dec/12 ]

If there already exists a mapping for key, it just replaces the old value with the new one(similar to Map).





[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-10] Clarify default provider class loading semantics Created: 07/Sep/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

Status: Closed
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If a OSGi bundle includes both api+impl without META-INF/services entry, the default impl won't be loaded by TCC(since TCC may be webapp classloader)



 Comments   
Comment by jitu [ 27/Nov/12 ]

Not specifying how a default provider is loaded.

  • Also considered specifying a system property for a provider name. The order considered was:
    1) system property
    2) ServiceLoader
    3) default provider

That doesn't work well when a webapp bundles its own provider in a war file (if a system property is already defined).

  • If we define the order to be
    1) ServiceLoader
    2) System property
    3) default provider

then system property doesn't work well(since one of the providers are picked up using ServiceLoader).

so not specifying system property as it is of limited use.





[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-2] A reader.readObject() call that reads JsonObject stream with duplicate keys should throw exception Created: 03/May/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

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


 Description   

reader = new JsonReader(new StringReader("

{\"foo\":\"bar\",\"foo\":\"foo\"}

"));
JsonValue jv = reader.readObject();

It seems that the above readObject() should throw an exception if duplicate keys exist within an object.



 Comments   
Comment by jitu [ 12/Dec/12 ]

It just overwrites the mapping with new values(similar to Map)





[JSON_PROCESSING_SPEC-1] Do not require that all content end up in String or char[] Created: 04/Feb/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

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

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


 Description   

In my work on the JRuby project, it has become painfully obvious that many Java APIs lose performance out of the gate because of the cost of decoding all incoming bytes to char[] before processing them. This also makes it difficult for JVM languages that use a different String representation to use those APIs.

I propose that the JSON processing API for Java should not impose String or char[] on consumers unnecessarily. In the style of the "spymemcached" library, it should be possible to register a factor that can create strings of other forms directly from the incoming bytes, allowing for parsing and processing JSON without ever decoding. This would make it possible (and may be necessary) to match the performance of C-based libraries, and allows consumers that do not want decoded characters/strings to use the raw bytes directly.

I will be monitoring this JSR once activity begins and discussions are made public.



 Comments   
Comment by headius [ 04/Feb/12 ]

My description should read "register a factory" instead of "register a factor".

Comment by jitu [ 13/Jun/12 ]

Updating the issue with some related discussion:

http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/0
http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/2
http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/22
http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/23
http://java.net/projects/json-processing-spec/lists/users/archive/2012-04/message/25

Comment by jitu [ 21/Nov/12 ]

We are supporting byte streams, but we are not exposing byte[] in parser or JsonString. I think that would be less useful for developers. Moreover, one needs to encoding of the underlying stream to use it.

Comment by headius [ 26/Nov/12 ]

I hope you can elaborate on that a bit. Supporting byte streams but still transcoding everything to UTF-16 char strings would defeat all the gains of being able to work directly with bytes.

The factory suggestion still seems like the cleanest way. In an ideal world, we'd be able to register a factory that receives the incoming byte[] + offsets and we can then construct whatever string-like structure we want from that. It would avoid unnecessary transcoding for languages and libraries that can work directly with bytes, and it would eliminate lots of transient objects and overhead from going to String eagerly.

I'd like to understand better what you mean by "supporting byte streams".

Comment by jitu [ 26/Nov/12 ]

We are supporting creation of parser objects using byte streams like InputStream (rather than character streams like Reader). Some of the provider impl take advantage of working with byte streams for certain encodings and don't convert to characters internally.

At the application level, most users would be consuming them as String and the provider impls produce the String when it is asked. The pull parser is lazy in that sense. You are suggesting to add something like the following approaches:

1) A way to register/use factory
JsonParser

{ void setFactory(SomeFactory<T> f) // valid in VALUE_STRING, KEY_NAME states // go through SomeFactory to create T T getStringObject(byte[] buf, int offset, int len) }

or

2) one other alternative using already existing JsonString interface

JsonParser

{ + JsonString getString(); }

// May be existing JsonString is good enough(no need to add additional methods like getBytes etc)
JsonString

{ .. + byte[] getBytes(); + Charset getCharset(); }

I think exposing bytes doesn't work well at the application level for various reasons. One of the reasons is escaping of characters and one cannot expose the internal buffer directly as it is. I think a custom provider and a subtype of JsonParser would be good for this case.

I will start a thread on the users list. Please follow there.

Comment by jitu [ 30/Nov/12 ]

Resolving without any action as per the discussion
http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/81





Generated at Tue Apr 21 12:44:42 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.