Support copy/cloning of JsonObject and JsonArray

[GoogleCodeExporter]

The above two objects are not immutable so it would be nice to make a defensive 
copy in some cases to ensure the internals of your object do not get modified 
by others if you leak out this object via a getter.

Original issue reported on code.google.com by joel.leitch@gmail.com on 22 Mar 2011 at 10:19

[GoogleCodeExporter]

This issue was closed by revision r855.

Original comment by limpbizkit on 17 Jun 2011 at 9:46

• Changed state: Fixed

[GoogleCodeExporter]

When are we planning to include this fix into newer version of gson jar?

Original comment by taps...@gmail.com on 28 Oct 2011 at 5:50

[GoogleCodeExporter]

What were the reasons to remove this with r1010? I was hoping this landed with 
2.1

Original comment by oliver.s...@gmail.com on 3 Jan 2012 at 1:43

[GoogleCodeExporter]

We decided against it because we decided that it encourages mutable objects. 
You can implement this yourself relatively easy in application code so it isn't 
a big loss.

Original comment by limpbizkit on 4 Jan 2012 at 1:05

[GoogleCodeExporter]

I think this should be revisited. How can you claim it's "relatively easy" to 
implement it ourselves when you had to touch 5-10 lines in 5 application 
classes?

If you don't want to support deep clones, then can you support immutable 
versions of each of the Json* types? The current situation could inadvertently 
lead to all sorts of aliasing bugs.

Original comment by bolinf...@gmail.com on 24 Apr 2013 at 3:40

[GoogleCodeExporter]

bolinfest: what's your proposal to make Json* types as immutable? JsonObject 
and JsonArray are designed as mutable types. Are you thinking of a 
Collections.unmodifiableList() type of method?

Original comment by inder123 on 24 Apr 2013 at 6:19