[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





[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-5] Super type for JsonArray and JsonObject Created: 13/Jun/12  Updated: 03/Dec/12  Resolved: 01/Aug/12

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

Need a common supertype for JsonArray and JsonObject. Otherwise, the object model API
has two "top level" types and that looks odd. A common type would make it easy to pass
JSON text around. The changes would be:

public interface JsonText {
}

public interface JsonArray extends JsonValue, JsonText {
}

public interface JsonObject extends JsonValue, JsonText {
}

public class JsonBuilder {

public static interface JsonBuildable<T extends JsonText>

{ ..}

...
}

public class JsonWriter implements Closeable {
public void write(JsonText value)

{ ... }
}

public class JsonReader implements Closeable {
public JsonText read() { ... }

}

Can also use JsonDocument instead of JsonText, but JsonText is preferred as it is
used by grammar.

Perhaps, we also need to add START_TEXT, END_TEXT parser events.



 Comments   
Comment by jhorstmann [ 13/Jun/12 ]

Isn't JsonValue already the common supertype?

From the grammar in the rfc, json text would be the serialized form of an object or array. I think this distinction between serialized form and object model should be made clear in the api, as that is not always the case with other json libs.

The only common property of object and array would perhaps be a 'size' property. If you think another interface would be useful then I would suggest a name like JsonContainer or JsonStructure. The term structure also appears in the rfc, but might be mistaken for a C struct, which is more like a json object.

Comment by jitu [ 13/Jun/12 ]

JsonValue is a supertype of JsonArray/JsonObject but that also includes other values like JsonString, JsonNumber etc. Hence the new type.

Your have a point about serialized form and the use of JsonText etc. Simiarly, some suggested to use JsonMap/JsonList instead of JsonObject/JsonArray(when I experimented with this, this renaming is not coming out well).

Comment by jitu [ 01/Aug/12 ]

Let me use JsonStructure for now. If we find a better name, we will use it.





[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-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-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-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-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-16] java bean direct to json string Created: 24/Oct/12  Updated: 25/Oct/12  Resolved: 25/Oct/12

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

Type: New Feature 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   

now jsonp only support:
json object -> json string
json string -> json object

it should support:
javabean -> json string
json string -> java bean

it's simple use, and good performance.

like fastjson's api:

com.alibaba.fastjson.JSON.toJSONString(Object)

demo:
https://github.com/AlibabaTech/fastjson/blob/master/src/test/java/com/alibaba/json/demo/Demo2.java



 Comments   
Comment by wenshao [ 24/Oct/12 ]

json string -> java bean :

VO vo = JSON.parseObject("...json string...", VO.class);

Comment by wenshao [ 24/Oct/12 ]

in the china, fastjson is very popular. it's really fast.

https://github.com/eishay/jvm-serializers/wiki/Staging-Results

6 times performance to gson, 2 times performance to jackson, 50 times performance to json-lib.

it's simple to use:
String jsonString = JSON.toJSONString(javaBean);
VO vo = JSON.parseObject("...json string ...", VO.class);

Comment by jitu [ 24/Oct/12 ]

This is outside of the current JSR scope. There will be JSON-Binding JSR that would address this usecase

Comment by jitu [ 25/Oct/12 ]

Resolving this one as this is outside the JSR scope





[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-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-25] Provide read() methods to retrun Map<String,Object> and List in JsonReader Created: 27/Nov/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

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

Type: Improvement Priority: Major
Reporter: Sutanu Ghosh Assignee: Unassigned
Resolution: Invalid 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 Sutanu Ghosh [ 27/Nov/12 ]

Please close. Bad description when I cloned another one.

Comment by jitu [ 27/Nov/12 ]

Closing a per the user request





[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-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)





Generated at Sat Sep 05 08:12:35 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.