Are there any situations where having a "data model" in which all of the entities are instances of a Map<String, Object> would make any sense?

How do you explain to someone why having such a "data model" is not such a good idea? It seems like it's an absurd approach to me, could I be missing something?

  • 2
    It does seem odd, but no-one can answer until we hear what were the considerations for choosing to model your entities as maps. Maybe they make sense, who knows? (Probably not, but we need more info!)
    – Andres F.
    May 18, 2012 at 12:27
  • 1
    -1 for not explaining what is specifically "absurd"
    – gnat
    May 18, 2012 at 15:28
  • 1
    when you are creating a cache implementation ? Jun 6, 2012 at 10:14
  • It smells of object denial. Jun 6, 2012 at 10:15
  • 2
    Basically, that's how objects in JavaScript work (plus prototype-based inheritance). In Java, I assume this to be an example of the en.wikipedia.org/wiki/Inner-platform_effect
    – user281377
    Jun 6, 2012 at 11:28

3 Answers 3


It isn't necessarily a bad idea to have a data model that's a map of key strings to values. However it often is a good idea to abstract that behind something domain specific, both to give some meaning to the strings and objects and to offer somewhere to impose any constraints that aren't evident from the underlying data structures.


If you're mapping Maps then sure. But generally you want to ask what is it a Map of that you're modelling? A Map of Cats? a Map of Nodes? etc.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.