Andres Almiray's Weblog

Its just been a couple of days after Json-lib 2.1 was released and feature requests are already pouring in. The first one ask for custom handling of default values when a null reference is encountered. Per the JSON spec if a value is null Json-lib applies the following rules But what if you would like to return 'null' if an Integer reference is null? (yes I know that would against the spec), or if a MyCoolBean reference is null you'd like to return '{ empty: true }' instead of simply 'null'? that's the reason why DefaultValueProcessor is now available, along with DefaultValueProcessorMatcher (for the same reasons shown here).

The second feature caught me by surprise as I didn't understand the usefulness of it at first sight, the thing is that a user has a bean which uses a composed Map for its property representation, but that bean does not implements Map nor it is a DynaBean, so he would like to call internalMap.put() instead of going to trough the usual PropertyUtils.setProperty(), which depending on the client code can be sometimes a performance bottleneck. After a quick message exchange and a prompt patch PropertySetStrategy is ready.

These features have a default implementation already plugged into JsonConfig, which is the place where you would also plug-in your custom implementations.

The third one is related to JSON <-> serialization. As you may probably know, XMLSerializer will output type hints (unless configured otherwise) to an XML string, using those hints again when transforming back to JSON. The hints use reserved keywords as attributes [type,class,params,null] but it may be the case for some users that some of those keywords must have business meaning instead of just 'framework' meaning, how do we cope with that? by adding a 'json_' prefix to the reserved keywords. In order to maintain backward compatibility there is a flag on XMLSerializer (typeHintsCompatibility) that when set to false will enable the prefix, when true it will disregard it.

The code is already on the cvs along with a couple of quick bug fixes. Keep posted for more Json-lib updates.

features json json-lib xml

Dear JRoller Community,
I'm pleased to announce that Json-lib version 2.0 has been released.

Download | Documentation | Faq | Changes

JSON-lib is a java library for transforming beans, maps and XML to JSON and back again to beans and DynaBeans. It is based on the work by Douglas Crockford in http://www.json.org/java.

Changelog:

features groovy jruby json json-lib release xml

While testing the new features on XML in Json-lib 1.1 I stumbled across a couple of improvements that will make the JSON output more JSONy (dibs on the phony word). Let's say for example that you'll want to transform your del.icio.us bookmarks rss feed into a JSON string, you'll fire up your favorite IDE, configure Json-lib-1.1 in your classpath, get a copy of the rss and pass it through the XMLSerializer, the result is... well is not pretty and its hard to read. That is because the input XML has namespace declarations, and as XOM is a very nice and strict XML parsing library, it will add namespace information to every namespace prefixed element, resulting in a lot of @xmlns properties in your JSON.

So what if we had an option to skip inserting those namespace declarations ? and while you're at it, why not also trim the prefixes if any? and surely you have noticed that sometimes the value of an element may have leading and trailing spaces that may not be needed, so let's add another option to get rid of them.

With these new features in place we can go from this: <?xml version=\"1.0\" encoding=\"UTF-8\"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:cc="http://web.resource.org/cc/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/"> <channel rdf:about="http://del.icio.us/aalmiray/javascript"> <title>del.icio.us/aalmiray/javascript</title> <link>http://del.icio.us/aalmiray/javascript</link> <description></description> <items> <rdf:Seq> <rdf:li rdf:resource="http://www.sergiopereira.com/articles/prototype.js.html" /> </rdf:Seq> </items> </channel> <item rdf:about="http://www.sergiopereira.com/articles/prototype.js.html"> <title>Using prototype.js v1.5.0</title> <link> http://www.sergiopereira.com/articles/prototype.js.html </link> <dc:creator>aalmiray</dc:creator> <dc:date>2007-01-03T19:25:20Z</dc:date> <dc:subject>guide javascript prototype</dc:subject> <taxo:topics> <rdf:Bag> <rdf:li resource="http://del.icio.us/tag/javascript" /> <rdf:li resource="http://del.icio.us/tag/prototype" /> <rdf:li resource="http://del.icio.us/tag/guide" /> </rdf:Bag> </taxo:topics> </item> </rdf:RDF>
to this:
{ "item": { "@about": "http://www.sergiopereira.com/articles/prototype.js.html", "topics": {"Bag": {"li": [ {"@resource": "http://del.icio.us/tag/javascript"}, {"@resource": "http://del.icio.us/tag/prototype"}, {"@resource": "http://del.icio.us/tag/guide"} ]}}, "title": "Using prototype.js v1.5.0", "subject": "guide javascript prototype", "link": "http://www.sergiopereira.com/articles/prototype.js.html", "date": "2007-01-03T19:25:20Z", "creator": "aalmiray" }, "channel": { "@about": "http://del.icio.us/aalmiray/javascript", "title": "del.icio.us/aalmiray/javascript", "items": {"Seq": {"li": {"@resource": "http://www.sergiopereira.com/articles/prototype.js.html"}}}, "description": null, "link": "http://del.icio.us/aalmiray/javascript" } }
with as little configuration like:
XMLSerializer xmlSerializer = new XMLSerializer(); xmlSerializer.setSkipNamespaces( true ); xmlSerializer.setTrimSpaces( true ); xmlSerializer.setRemoveNameSpacePrefixFromElement( true ); JSON json = xmlSerializer.read( xml.toString() );
instead of what you'll currently get:
{ "item": { "title": "Using prototype.js v1.5.0", "@rdf:about": "http://www.sergiopereira.com/articles/prototype.js.html", "taxo:topics": { "rdf:Bag": { "rdf:li": [ { "@resource": "http://del.icio.us/tag/javascript", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, { "@resource": "http://del.icio.us/tag/prototype", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, { "@resource": "http://del.icio.us/tag/guide", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" } ], "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, "@xmlns:taxo": "http://purl.org/rss/1.0/modules/taxonomy/" }, "dc:subject": "guide javascript prototype", "dc:creator": "aalmiray", "link": " http://www.sergiopereira.com/articles/prototype.js.html ", "dc:date": "2007-01-03T19:25:20Z", "@xmlns": "http://purl.org/rss/1.0/", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, "@xmlns:taxo": "http://purl.org/rss/1.0/modules/taxonomy/", "@xmlns:cc": "http://web.resource.org/cc/", "channel": { "title": "del.icio.us/aalmiray/javascript", "@rdf:about": "http://del.icio.us/aalmiray/javascript", "items": { "rdf:Seq": { "rdf:li": { "@rdf:resource": "http://www.sergiopereira.com/articles/prototype.js.html", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, "@xmlns": "http://purl.org/rss/1.0/" }, "description": null, "link": "http://del.icio.us/aalmiray/javascript", "@xmlns": "http://purl.org/rss/1.0/", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }, "@xmlns": "http://purl.org/rss/1.0/", "@xmlns:syn": "http://purl.org/rss/1.0/modules/syndication/", "@xmlns:rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", "@xmlns:dc": "http://purl.org/dc/elements/1.1/", "@xmlns:admin": "http://webns.net/mvcb/" }
In conclusion, while Json-lib-1.1 represents a lot for XML writing, it still has some issues with reading, which will be covered by the next release. Hopefully that release will also include another feature that has been requested a lot lately: custom serialization from Java to JSON.

features json json-lib xml

Following the recent updates on XML processing in Json-lib, now its possible to work with namespace prefixes and uris. If you feed an XML to the XMLSerializer and that XML has namespace declarations, each declaration will be added with a "@xmlns" prefix to the resulting JSONObject. The namespace handling has one side effect, previously you could read an array definition and the resulting object would be a JSONArray, because arrays do not have properties and the xmlns is a property, the resulting object would be a JSONObject.

Writing namespace declarations is also possible and in that topic there also new features and one side effect. If a namespace declaration or a prefixed element name is detected, the XMLSerializer will change to namespaceLenient mode automatically (last update you had to turn in on before processing the xml). The new features include a couple of methods that will let you set an arbitrary namespace attached to the root or an specific element as you may see fit. Additional namespaces may be added or removed. Finally there is an option to clear or namespaces defined in the XMLSerializer. Namespaces defined on the XMLSerializer have a higher precedence that those defined in the JSONObject to be processed.

Parallel to these new enhancements I'm still working on reworking the type handling mechanism to allow for custom serialization of Java objects (many have expressed the need for a custom serialization of java.util.Date into a JS compatible Date).

features json json-lib xml

Previously I described the new changes on Json-lib when writing a JSONObject/JSONArray, it is now the turn for the read operation. Reading from XML was really simple, it discarded all non Json-lib specific attributes and only considered child Elements (Text nodes were not in the picture), well that's old history, today with the development version you can read from an XML all attributes and nodes because Json-lib now supports the transformations shown at Converting Between XML and JSON and that includes writing back to XML too with the caveat that the order of several Text nodes mixed with elements is not preserved (as described in that article).

You may be wondering, what happens if an XML element with attributes is transformed to a JSONObject and then that JSONObject into a JavaBean or DynaBean, a JSONException? yes and no, it turns out there is another feature (which was previously missing, I'll show you why) that can transform a JSONObject key into a valid Java identifier, using a conversion strategy, for which Json-lib includes 4 and you have the option to define yours as well: This feature was missing because the JSON spec lets you define a key with any chars surrounded by quotes (single or double), and that includes whitespace and other chars not valid as part of a java identifier, but because almost everyone is using sound names for their keys when transforming from and to Java this feature was overlooked.

Now what do you think about the XML support Elliotte? is it like you previously expected?

Feedback (of all kind) is always appreciated.

features json json-lib xml

In the last days I've been working on revamping the XML processing capabilities of Json-lib. It is no secret that with the rise of web 2.0 XML and JSON are used everywhere as data interchange formats, and sometimes you'd like to transform one into another, problem is that their structures are not very compatible and a set of transformations (some of them are one-way only) need to be applied as the ones described at Converting Between XML and JSON), which will be included in the next release.

Now imagine for a moment that you receive a json string that is the result of some transformation from an xml document, and said transformation was made in a "naive way" (not having in mind some of the previous mentioned transformations) like the following:
<root> <id>1</id> <element> <id>1.1</id> <value>foo</value> </element> <element> <id>1.2</id> <value>bar</value> </element> </root>
{ "id": 1, "element": { "id": 1.1, "value": "foo" }, "element": { "id": 1.2, "value": "bar" } }
which is clearly not a correct json string because the element property is repeated. If you pass this string to the JSONSerializer it will fail (Json-lib 1.0) but in the next release it will be possible to parse an create an explicit array named element, resulting in the following correct json:
{ "id": 1, "element": [ { "id": 1.1, "value": "foo" }, { "id": 1.2, "value": "bar" } ] }
If you'd like to transform back this json string into xml, the XMLSerializer will see the explicit array and create the elements inside the parent of the array and not the array itself, in other words, it will revert back to an implicit array. How is this possible? because the explicit JSONArray will remember that information with a flag, that can be turned on and off at your leisure.

There will also be another option when working with the XMLSerializer to choose which arrays will behave in this way but by specifing a property name like:
/* JSONObject was constructed with * { * "id": 1, * "element": [ * { * "id": 1.1, * "value": "foo" * }, * { * "id": 1.2, * "value": "bar" * } * ] * } */ JSONObject jsonObj = JSONObject.fromObject( str ); XMLSerializer xmlSerializer = new XMLSerializer(); xmlSerializer.setRootName( "root" ); xmlSerializer.setExpandableProperties( new String[]{ "element" } ); String xml = xmlSerializer.write( jsonObj ); // xml should be equal to the above xml snippet
Other new features:
More to come.

features json json-lib xml

Well, I've started work on the next version of Json-lib. I began by adding Map and List implementations of JSONObject and JSONArray respectively, everything was coming up nicely until I hit equals and hashCode, the reason being that two JSONObjects may have an attribute named "mynumber" for which the first stores a Double and the second stores a String and the logical values must match. Now this has already been accomplished by JSONAssert, but the Cyclomatic Complexity of its methods is huge! so I had to consider an alternative.

Luckily, there is another feature that I've been itching to implement, a BeanInfo-like approach for custom serialization, which will allow users to plug-in type handlers. Solving that issue means that the type handlers must conform to the specification and an internal validator must be put in place. This validator and a generic type/value representation is what is needed for equals and hashCode to work appropriately.

In short, these two issues will reshape the inernals of JSONObject and JSONArray to their very cores, but don't worry, I won't throw backwards compatibility out of the window just yet, these changes must be as transparent as possible.

Also in the list is the improvement of XML support, for which Elliotte Rusty Harold said "It appears to me [from reading your site] that Json-lib cannot convert an arbitrary XML document to JSON and back without losing information", which at first I thought that it was not an issue until one of my colleagues at JackBe tried to transform a XML schema into JSON and the result was not as expected (the output came almost empty). To be fair, the XML support in Json-lib was not planned to be as thorough as ERH seems to think it should be, because besides getting a request on xml encoding configuration, there are no other requests on it. Nevertheless as XML has been ubiquitous to the web since its early days and now that JSON is posed to dethroned it as the defacto language for data representation on the web (not to spur a new debate on XML vs JSON), they should at least cooperate with each other.

I found an interesting and insightful link on XML to JSON transformation ideas: Converting Between XML and JSON, this should give you an idea on where the solution might go to.

features json json-lib xml