Well few examples I found are:
- in Apache Camel documentation for CSV data format
Map<String, Object> body = new HashMap<String, Object>(); //...
- in Atlassian Java cookbook, Converting a Map to JSON
Map<String, Object> data = new HashMap<String, Object>(); //...
- in Spring JDBC API, queryForMap API docs
Map<String,Object> queryForMap(String sql, Object... args) //...
The way I see it, it boils down to a pretty simple question.
1234 - what type is it? is it... Integer? or String, or Long, or maybe, Double?
When there is a context one can learn about semantics of the data, above question is easy to answer. But what if there is no such context? this seem to be pretty common case in data passing frameworks.
Imagine writing a library that passes data from various sources to different consumers. One source can pass
1234 as String, another as Integer - you just have no reason to prefer one over another. As for the consumers, they "know" what type they expect from particular source, but why would they "tell" you?
If you slavishly follow the never an Object dogma, you might be tempted to arbitrarily cast everything to some type you just happen to prefer, like say String. The problem is though, this will make your library harder for clients to understand, not easier - they will break their mind trying to figure why did you use that type and what could be consequences.
Why String? I plan to plug data source that passes Double, what will happen? Will you convert? or will you break? Also, my consumer expects Double, does that mean I have to convert back? by the way how do you convert - does locale matter? Oh and another thing, in my other module I plan to use data source that passes Long and consumer that expects Long, too - could there be problems with that?
I did not use CSV, JDBC, JSON libraries mentioned in examples below, but in one of my past projects there has been
Map<String, Object> used in a proprietary data passing framework and have to admit, as its client I've got nothing to complain against.
One interesting thing I noticed about that proprietary framework is that they did not intrude their untyped Objects into my client code. They exposed data through some API layer that presented it to me using the types I needed.
Actually I only learned about
Map<String, Object> through one auxiliary "escape hatch" method in their API. I don't remember if method javadocs explicitly mentioned that it is for debugging purposes, but that was my understanding of why it's there.
If I mis-configure data source so that it passes String where I expect Integer, I would prefer to test the
Object that is being passed under the hood instead of staring at cryptic ClassCastException. For that, I'd use "escape hatch" API.
Summing up, (1) I can imagine a library where using untyped Object makes better sense than pulling arbitrary type out of thin air and (2) at client code, I'd be be OK with that library as long as (2a) library API presents data with needed type and (2b) there is a convenient way to debug stuff when things go wrong.