JSONObject should extend LinkedHashMap to preserve order of key-value pairs

[GoogleCodeExporter]

The decoding/encoding cycle of json objects with json-simple is not "stable"
since the ordering of the key-value pairs is not maintained by the parsing code.



What steps will reproduce the problem?
1. Parse a json-string of an object, ie:
   {"key1":"val1","key2":"val2","key3":"val3","key4":"val4"}.
2. Then write back that same object and the order of the key-value pairs are 
not preserved,
but they get the random ordering of the java.util.HashMap, ie:
  {"key2":"val2","key3":"val3","key1":"val1","key4":"val4"}


What version of the product are you using? On what operating system?
  version 1.1


I can think of 2 obvious solutions:

1) either to provide a ContainerFactory that returns the a LinkedHashMap,
but a subclssing might be required for its toString() method to emit proper 
json as the replaced JSONObject class does, 

2) modify the JSONObject code to extend from LinkedHashMap instead of from 
HashMap.

Original issue reported on code.google.com by ankos...@gmail.com on 2 Sep 2010 at 4:30

[GoogleCodeExporter]

You can provide a ContainerFactory to get a LinkedHashMap during decoding:
http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_4_-_Container
_factory

And then use JSONValue.toJSONString() to encode the object: 
http://code.google.com/p/json-simple/wiki/EncodingExamples#Example_1-3_-_Encode_
a_JSON_object_-_Using_Map

Then you will get what you expect.

Original comment by fangyid...@gmail.com on 2 Sep 2010 at 4:51

• Changed state: WontFix

[GoogleCodeExporter]

Original comment by fangyid...@gmail.com on 2 Sep 2010 at 4:52

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Should'nt this be considered a possible fix for the next release?

Original comment by ankos...@gmail.com on 2 Sep 2010 at 5:45

[GoogleCodeExporter]

Just to note that LinkedHashMaps are somewhat slower for get and put operations 
than regular HashMaps. So some people may be interested in keeping good 
performance than maintaining object member order.

Original comment by vladimir...@gmail.com on 9 Mar 2011 at 1:50

[GoogleCodeExporter]

I attached 2 performance tests for constructing hash-map/linked-hash-map:
  1) inserts 1.5M integers into each map, and
  2) creates many(1.5M) small(<10 keys) maps.

Here are the results:
  Many-keys(1500000)   delay: mean(-14,63%), stdev(1,86%)
  Many-hashes(1500000) delay: mean(23,40%),  stdev(5,18%)

Interestingly enough, linked-hash is actually faster(!) when inserting 
many-keys.
I'm suspecting it is due to the improved re-sizing of linked-hash-tables.

But it is ~23% slower when creating a lot smaller hashes.

I expect searching into the hashes to be exactly the same.


TEST-ENV:
  java.version=1.6.0_22, 
  java.runtime.version=1.6.0_22-b04, 
  java.runtime.name=Java(TM) SE Runtime Environment, 
  java.vendor.url=http://java.sun.com/,
  java.vm.version=17.1-b03, java.vm.vendor=Sun Microsystems Inc.,
  java.vm.info=mixed mode, 
  java.vm.name=Java HotSpot(TM) Server VM, 
  sun.management.compiler=HotSpot Tiered Compilers, 
  os.arch=i386,
  os.version=2.6.36-ck-r3, 
  os.name=Linux

Original comment by ankos...@gmail.com on 9 Mar 2011 at 5:12

Attachments:

• CheckLinkedHashPerf.java

[GoogleCodeExporter]

Issue 40 has been merged into this issue.

Original comment by fangyid...@gmail.com on 10 Mar 2011 at 10:14

[GoogleCodeExporter]

If you are using the Transformer code to collect the Json Strings as
JSONObject +JSONArrays, would it not be better to have theJ SONObject extend
LinkedHashMap as ooposed HashMap to preserve the order of elements

regds,
Chiths

Original comment by chi...@gmail.com on 11 Mar 2011 at 3:08