Jackson: Known Issues
(list updated last 08-Sep-2009, at around time of 1.6.0 release)
Beyond immediate issues like bugs (which can be viewed at Jackson Jira), there are some general issues that should be overcome in future. Here are some that are known to the development team.
1. Extensibility, Customizability challenges
Sep-2010: This will be THE area to tackle with Jackson 1.7, as it was one of things left off of 1.6 plans.
How to plug in 3rd party extensions?
Currently extensing set of types that Jackson can handle (beyond simple beans that require no additional functionality) can be done in one of two ways:
- Add explicit support in core Jackson mapper package
- Explicit adding custom deserializers/serializers
This works for application-provided types, as well as for "core" JDK types. However, there is no mechanisms for 3rd party library authors to plug-in some sort of bundles to optionally support set of types that a library or framework provides. Although it is possible for such libraries to use Jackson annotations to possibly achieve this, this is considered intrusive as it requires those libraries to depend on Jackson; something that seems conceptually wrong.
Going forward it would be good to design a simple interface that would allow for "bulk registration" of external types, such that simple add-on libraries or jars could extend Jackson type support without direct dependency either from Jackson to external libraries or vice versa.
2. Serializers vs Deserializers
Fundamentally Jackson considers serialization and deserialization to be independent of each other. This is different from how many (perhaps most) other data binding and serialization libraries work: JAXB, for example, requires properties to have both getters and setters to be visible. Jackson does not add such requirements, mostly because many use cases are asymmetric: if all you want to do is produce JSON, why should you have to add setters for reading JSON to objects?
However: although it is good to avoid tight coupling between these two sides, strict separation has some unfortunate side effects.
Redundant settings
There are many configuration settings that apply to both serialization and deserialization, but configuration is strictly divided between separate sets. What would be a good way to handle such shared configuration settings? One challenge is that Java enums are not extensible, so sub/supersetting simple on/off features is not easy.
Separate code
Because JsonSerializer and JsonDeserializer are abstract classes, not interfaces, it is not possibly to define converters that would implement both; this is unfortunate. For next major version (2.0), it might be possible to change this -- such change would be mostly non-backwards-compatible, no matter how it is done; but would make sense from design/architectural standpoint.
3. Serialization
No Context
Sep-2010: This will be THE area to tackle with Jackson 1.7, as it was one of things left off of 1.6 plans.
Unlike deserializers, serializers do not get passed a per-operation context that can be used for storing and passing state. This is a limitation now, and will be even bigger one once more difficult object serialization aspects (identity, references, cyclic structure detection) are to be tackled. It may be necessary to change JsonSerializer interface so that instead of passing SerializerProvider around, a context object (SerializationContext?) would be passed.
Cyclic Graphs: detection, resolving
Currently there is no handling for cycles, except for simple detection of self-references (which causes exception). Adding detection is one of future things: it needs to be something to optionally enable due to additional costs (needed to keep track of already seen references).
But beyond detection, it would also be nice to handle cyclic references in some other way than failing serialization. First step could be to just call secondary serializer for such values, which could replace such references with custom-defined serialization. But ideally one should be able to actually replace values with some kind of reference identifier information.
Defining exactly how to handle references (including deserialization, see below) is a non-trivial problem, much of it due to JSON not having good mechanisms for adding metadata along with data. So coming up with full solution will take a while: and will not be tackled before implementing full Polymorphic deserialization (see below).
4. Deserialization
Polymorphic Deserialization
Hooray! As of Jackson 1.5, Jackson has completely, automatic and configurable support for polymorphic types.
Resolving cyclic references
Beyond problems with serializing cyclic references, there is the corresponding issue of deserializing them back: that is, two distinct references should be resolved back to a single object, to recreate cycle (that was broken by whatever mechanism is being used, most likely reference identifiers).
5. Type system, validation
Unlike XML which has W3C Schema (aka "XML Schema") that can work as a full-feature type system (even more so than as XML validation system), JSON does not have portable object description language. Although there is JSON Schema proposal, its goals are in much less interesting (IMO) direction of validation JSON object, but without much thought to how OO languages might map JSON into objects. It is a shame that this area is uncovered currently.
But since Java has reasonable type system (language itself), why does this matter? For code-first approach, it does not. But for cross-platform/language portability it would be good to also be able to do "schema-first" development: and that is where external type system is required.
One possibility is to start developing such a simple type system. If so, my thoughts on goals would be:
- Cover "common" OO typing aspects; basically, work well with languages like C# and Java, as well as with more dynamic scripting languages
- Not create or support JSON constructs that do not map nicely into OO language Objets
- Use intuitive, simple, but powerful-enough Domain-Specific Language (DSL) -- absolute not JSON itself. Somehow the call of orthogonality has made otherwise smart developers total morons, thinking schema/type-language needs to use format that is being described: this is absolute bollocks, especially so with JSON (can't use comments? you kidding me?)
As a smaller pain point, perhaps support for JSON Schema could be improved. I don't care too much about this -- Java Bean Validation seems like a much better approach for my own use cases, but some users like external schema languages for validation.