Jackson-databind: Consider adding `UncheckedObjectReader`/`-Writer` (or `Safe-`)

Created on 3 May 2015  路  4Comments  路  Source: FasterXML/jackson-databind

(note: inspired by #778)

Given that use of checked exceptions can be problematic for some use cases, perhaps it would make sense to implement an ObjectMapper-like abstraction that can wrap an actual ObjectMapper, but expose set of methods that do NOT throw IOException (and subtypes), but rather wrap such exceptions as RuntimeExceptions.

Actually, since it is ok for sub-class to remove exceptions from signature, this could just be a sub-class of ObjectMapper, for improved compatibility (cast as ObjectMapper there is no benefit wrt exception declarations, but it would work).
However, implementation should still use delegation model instead of sub-classing, to support use with other ObjectMapper subtypes, like XmlMapper.

This is a half-baked idea at this point, so feel free to add comments for improvements, or for/against the idea. Note however that API definition of ObjectMapper itself is not under discussion for Jackson 2.x, at least; and even for 3.x change to unchecked exceptions would be a major change and would need separate discussion.

3.x

Most helpful comment

Having thought bit more about this, I think it would make more sense to expose unchecked/"safe" variants of ObjectReader / ObjectWriter. Benefits there are:

  1. Since these are not sub-classed by other modules, we could just directly sub-class instances, AND they would work with other mapper variants (like XmlMapper or AvroMapper)
  2. Access could/should be via "mutant factory", to allow switching to "safe" instance as needed, even from "unsafe" (checked exceptions exposing) instance
  3. APIs are smaller so this is bit less work as well

All 4 comments

Having an API with unchecked exceptions would be very useful with Java8 lambdas, so +1 for this.

One note: subclassing may impose a performance hit on method dispatch (formerly monomorphic call-sites may become polymorphic). So perhaps delegation without subclassing might be appropriate.

Having thought bit more about this, I think it would make more sense to expose unchecked/"safe" variants of ObjectReader / ObjectWriter. Benefits there are:

  1. Since these are not sub-classed by other modules, we could just directly sub-class instances, AND they would work with other mapper variants (like XmlMapper or AvroMapper)
  2. Access could/should be via "mutant factory", to allow switching to "safe" instance as needed, even from "unsafe" (checked exceptions exposing) instance
  3. APIs are smaller so this is bit less work as well

While no work has started here, I think that work towards builder-based ObjectMapper construction should help a lot here. That should allow easy(-ier) and cheap(er) wrapper-based approach, so that regular mapper (of format-specific type, if need be) can be wrapped, without requiring sub-classing.

Or, alternatively, if sub-classing seems desireable, should be much easier to pull off as-well.

This will actually be resolved by quite a different approach: just make exceptions unchecked in 3.x:

https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-4

Closing this issue.

Was this page helpful?
0 / 5 - 0 ratings