Jackson: TODO
Although Codehaus Jackson Jira contains extensive list of planned features, it may be difficult to clearly see main areas of improvement that are currently planned, or that the development team is at least aware of. Here is an overview of such areas.
Areas at not listed in strict order of priority: such ordering would be difficult since different users have different needs.
1. Code Generation
1.1 Existing
As of Jackson 1.6, functionality ("mr Bean") exists to automatically "materialize" Bean-style interfaces and abstract classes. This is a good start.
Beyond basics, there are many other areas where code generation could be used to enhance functionality:
- For high(er) performance, code generation could be used for creating Bean Serializers and Deserializers; probably simpler to start with serializers.
2. JSON Path
(and JSON Query)
Currently JsonNode-based Tree Model only offers direct traversal methods. To improve usability it would be good to allow more effective access, similar to how XPath is used with XML.
Basic name-based lookups would be an easy addition, but implementation actual path language (like JsonPath) would be even better.
3. JSON Schema
Currently Jackson can generate JSON Schema instances using ObjectMapper.generateJsonSchema, but there is little additional functionality. Going forward, it would be great to add:
Code generation from schema: similar to how JAXB implementations have code generation from XML Schemas.
Schema-based validation: ideally it should be possible to plug in a validator into a JsonParser and JsonGenerator
4. Handling of cyclic references
Currently Jackson does simple value-based serialization, without considering equality of referenced Objects. That is, it assumes that all Objects given form a non-cyclic Tree. Directed-Acyclic Graphs (shared referenced Objects, but no back references) are handled so that values are duplicated; and cyclic structures will cause an exception.
Instead it would make sense to allow handling of:
- Shared references: for initial instance, create a reference id, output along with object data. And for subsequent references just serialize reference id.
- Cyclic references: allow handling using:
- Shared references (see above)
- Remote (serialize as null) -- avoids exception, does not require additional reference id metadata
Report error immediately when detected (instead of possibly causing StackOverflowError which can occur currently)
Since there can be significant overhead for tracking such references, and since serialization structure may change, such functionality needs to be something that can enabled/disabled via configuration.
4.1 Handling of bi-directional dependencies
As of Jackson 1.6 this has been implemented, see [JacksonFeatureBiDirReferences]!
5. Other languages
Some of known interoperability issues include:
- Scala lists (and maps) are not currently handled (since they are not JDK collections): would be great to handle them properly
With Jackson 1.7 there is new extension called Jackson Modules which should significantly simply adding support for third-party libraries and other JVM languages. As a result, there is now a sub-project Jackson-module-scala which is hoped to result in full support for Jackson-on-Scala.
There is also project Jerkson (not part of Jackson project) which seems promising as well, and already offers convenient access to Jackson JSON handling from Scala.
6. Extensibility
6.1 Ability to expose custom property annotations
Jackson 1.7 finally adds support for Contextual Handlers (serializers, deserializers), by adding ContextualSerializer and ContextualDeserializer interfaces. This allows for constructing specifically configured instances for properties; configuration can come from annotations associated with property (method, field).
6.2 Plug-in modules
Another important feature of Jackson 1.7 is Jackson Module API which makes it possible to write pluggable components that can be simply registered by:
objectMapper.registerModule(new ThirdPartyModule());
and where modules have convenient access for plugging functionality that augments existing functionality (usually by adding handlers for non-JDK datatypes). This is done in a way that should allow peaceful co-existence of multiple modules, each providing support for different data types.
7. XML Compatibility
Although "XML <> JSON" is a true statement, it would nonetheless be nice to add some more interoperability support.
To this end, with Jackson 1.7 a new external extension project jackson-xml-databinding was created to add "mini-JAXB" level support, via XML-backed ObjectMapper implementation (XmlMapper).