[Json-rpc-java] JSONMap and JSONList

[Arthur Blake]

On 8/23/06 (almost a year ago), a patch was made to the json-rpc-java
library to allow JSONObject and JSONArray objects to be passed directly to
and from js in the browser and java on the server.

This change was brilliant, and I use it a lot!

However, there is something to be desired.

For example, if I wanted to make a Map of bean objects in java and pass them
back to javascript, I can do it like this:

Map m = new HashMap();
m.put("bean1", new Bean(1));
m.put("bean2", new Bean(2));
// etc.
return new JSONObject(m);


however, it doesn't serialize in an intuitive way that I would expect.
Instead of each Bean in my JSONObject being serialized with the
BeanSerializer, it just does a toString() on each bean in the JSONObject.
This is understandable because the JSONObject itself isn't really aware of
json-rpc-java, and it's just blindly converting everything to json with it's
own internal rules.

I can hack the system so to speak to get it to work right, by doing
something like this when I add my beans:

JSONSerializer ser = JSONRPCBridge.getSerializer();
Map m = new HashMap();
try
{
  m.put("bean1", new JSONObject(ser.toJSON(new Bean(1))));
  m.put("bean2", new JSONObject(ser.toJSON(new Bean(2))));
} catch (ugly exceptions that could occur) {...}

return new JSONObject(m);

but it's not very pretty, and I have to also check for all the Marshall and
Unmarshall exceptions that could be thrown in my own code.

Another similar problem is that when I pass back regular old collection
objects, (Lists and Maps) I wish that they could get serialized directly
into json arrays and json objects without
having to use the javaClass wrapper semantics built into json-rpc-java
(that's just an extra layer of ugly boilerplate that I'd rather not use when
I have an existing json structure in mind.)

Wouldn't it be more beautiful and concise if my js objects would show up as
Maps in java automatically, and my js arrays would pop up as Lists directly?

In fact, if you think about this, it makes a lot of sense, because a js
array is a lot closer to a java.util.List then a typed java array (because a
List can contain objects of any type, just like in js.)

My proposed solution to both of the above problems is to introduce two new
objects, and custom serializers just for them.

By introducing two new objects, none of the current behavior will break, but
all the above could be handled by anyone who wants to use this new
methodology.

the new objects would be called,

JSONMap
and
JSONList

JSONMap will implement Map directly and be a thin layer wrapper around
another Map (HashMap by default when the no-arg constructor is used.)

similarly

JSONList will implement List directly and be a thin wrapper around another
List object (ArrayList by default when the no-arg constructor is used.)

So, in the above example, I would just code it like this:

Map m = new JSONMap();
m.put("bean1", new Bean(1));
m.put("bean2", new Bean(2));
return m;

much more concise and intuitive!

I'm going to write the code myself and try it out (because I could really
use it right now on a project) --
but I thought I would bounce the idea off you guys just in case someone has
some good feedback on the idea.
What do you think?

thanks.

Arthur