title: Why Guava does not provide a way to transform map keys
body: <p>This question is kind of already posted here:
  <a href="https://stackoverflow.com/questions/5733142/how-to-convert-mapstring-string-to-maplong-string-using-guava">How to convert Map&lt;String, String&gt; to Map&lt;Long, String&gt; using guava</a></p>
  
  <p>I think the answer of CollinD is appropriate:</p>
  
  <blockquote>
    <p>All of Guava's methods for transforming and filtering produce lazy
    results... the function/predicate is only applied when needed as the
    object is used. They don't create copies. Because of that, though, a
    transformation can easily break the requirements of a <code>Set</code>.</p>
    
    <p>Let's say, for example, you have a <code>Map&lt;String, String&gt;</code> that contains
    both "1" and "01" as keys. They are both distinct <code>String</code>s, and so the
    <code>Map</code> can legally contain both as keys. If you transform them using
    <code>Long.valueOf(String)</code>, though, they both map to the value <code>1</code>. They are
    no longer distinct keys. This isn't going to break anything if you
    create a copy of the map and add the entries, because any duplicate
    keys will overwrite the previous entry for that key. A lazily
    transformed <code>Map</code>, though, would have no way of enforcing unique keys
    and would therefore break the contract of a <code>Map</code>.</p>
  </blockquote>
  
  <p>This is true, but actually I don't understand why it is not done because:</p>
  
  <ul>
  <li><p>When the key transformation happen, if 2 keys are "merged", a runtime exception could be raised, or we could pass a flag to indicate to Guava to take any value of the multiple possible values for the newly computed key (failfast/failsafe possibilities)</p></li>
  <li><p>We could have a Maps.transformKeys which produces a Multimap</p></li>
  </ul>
  
  <p>Is there a drawback I don't see in doing such things?</p>