To answer your questions directly:

1. No, it will not affect performance much. Generics are mostly erased by the time the program gets executed anyway, so the additional cost is really only multiple (up to 3) map lookups instead of 1. I would not expect this to ever be a bottleneck in a scenario where usage of a standard HashMap is acceptable.

2. Not really. Generics are used for compile-time safety, and the compiler doesn't really like any unknown thing during compilation, including number of params. I hear C++ templates would do the trick, but that's quite a different beast (although often used for the same thing).

A couple of side comments about your approach:

1. At least the 2-key map is a very common problem, and a solved one. Look up Guava's Table - it's pretty much what you want, a table that has 2 keys, along with some additional bonuses.

2. Unless you need to query per-row or per-column maps separately (rather than just do single property reads or writes), a combined key is preferable when there are multiple dimensions. You can see how your signatures bloat in size. Whereas a simple key class will have it in a much more readable form.

3. If you insist on long generic type lists, then a much better way of doing this would be composition. It's what you're doing anyway, just without the clutter (you have 3 setProperty methods exposed in your "multimap", and if you decide you need a 4th param, the method will just keep on growing)

4. A Multimap is commonly known as a map of keys to collection of values, rather than map-to-map-to-map-to-values. Might confuse your teammates if you stick with that naming of your class :)

To answer your questions directly:

1. No, it will not affect performance much. Generics are mostly erased by the time the program gets executed anyway, so the additional cost is really only multiple (up to 3) map lookups instead of 1. I would not expect this to ever be a bottleneck in a scenario where usage of a standard HashMap is acceptable.

2. Not really. Generics are used for compile-time safety, and the compiler doesn't really like any unknown thing during compilation, including number of params. I hear C++ templates would do the trick, but that's quite a different beast (although often used for the same thing).

A couple of side comments about your approach:

1. At least the 2-key map is a very common problem, and a solved one. Look up Guava's Table - it's pretty much what you want, a table that has 2 keys, along with some additional bonuses.

2. Unless you need to query per-row or per-column maps separately (rather than just do single property reads or writes), a combined key is preferable when there are multiple dimensions. You can see how your signatures bloat in size. Whereas a simple key class will have it in a much more readable form.

3. If you insist on long generic type lists, then a much better way of doing this would be composition. It's what you're doing anyway, just without the clutter (you have 3 setProperty methods exposed in your "multimap", and if you decide you need a 4th param, the method will just keep on growing). All arguments for the "Composition over inheritance" principle set out by numerous people apply here as well.

4. A Multimap is commonly known as a map of keys to collection of values, rather than map-to-map-to-map-to-values. Might confuse your teammates if you stick with that naming of your class :)