2 Answers
2

The only caveat from the page you referred is that you can't be modifying configuration of the mapper once it is shared; but you are not changing configuration so that is fine. If you did need to change configuration, you would do that from the static block and it would be fine as well.

EDIT: (2013/10)

With 2.0 and above, above can be augmented by noting that there is an even better way: use ObjectWriter and ObjectReader objects, which can be constructed by ObjectMapper.
They are fully immutable, thread-safe, meaning that it is not even theoretically possible to cause thread-safety issues (which can occur with ObjectMapper iff code tries to re-configure instance).

Although it is safe to declare a static ObjectMapper in terms of thread safety, you should be aware that constructing static Object variables in Java is considered bad practice. For more details, see Why are static variables considered evil? (and if you'd like, my answer)

In short, statics should be avoided because the make it difficult to write concise unit tests. For example, with a static final ObjectMapper, you can't swap out the JSON serialization for dummy code or a no-op.

In addition, a static final prevents you from ever reconfiguring ObjectMapper at runtime. You might not envision a reason for that now, but if you lock yourself into a static final pattern, nothing short of tearing down the classloader will let you re-initialize it.

In the case of ObjectMapper its probably fine, but in general it is bad practice and there is no advantage over using a singleton pattern or inversion-of-control to manage your long-lived objects.

I would suggest that although static STATEFUL singletons are typically a danger sign, there are enough reasons why in this case sharing a single (or, small number of) instances makes sense. One may want to use Dependency Injection for that; but at the same time it is worth asking whether there is an actual or potential problem to solve. This especially applies to testing: just because something might be problematic in some case does not mean it is for your usage. So: being aware of problems, great. Assuming "one size fits all", not so good.
–
StaxManAug 8 '13 at 20:48

3

Obviously understanding the issues involved with any design decision is important, and if you can do something without causing problems for your use case you by definition you won't cause any problems. However I would argue there are no benefits to the use of static instances and it opens the door to significant trouble in the future as your code evolves or is handed off to other developers who might not understand your design decisions. If your framework supports alternatives, there is no reason not to avoid static instances, there certainly are no advantages to them.
–
JBCPAug 9 '13 at 21:45

3

I think this discussion goes into very general and less useful tangents. I have no problem suggesting that it is good to be suspicious of static singletons. I just happen to be very familiar for usage for this particular case and I do not think one can reach specific conclusions from set of general guidelines. So I will leave it at that.
–
StaxManAug 10 '13 at 20:35