8

With the following snippet I cannot retrieve gString from a map: 

def contents = "contents"
def gString = "$contents"

def map = [(gString): true]

assert map.size() == 1 // Passes
assert gString.hashCode() == map.keySet().first().hashCode() // Passes, same hash code
assert map[gString] // Fails

How on earth is that possible?

Assertion message clearly shows that there's something seriously wrong with Groovy:

assert map[gString] // Fails
       |  ||
       |  |contents
       |  null
       [contents:true]

It's not the same question as Why groovy does not see some values in dictionary? First answer there suggests:

You're adding GString instances as keys in your map, then searching for them using String instances.

In this question I clearly add GString and try to retrieve GString.

Also neither Why are there different behaviors for the ways of addressing GString keys in maps? nor Groovy different results on using equals() and == on a GStringImpl have an answer for me. I do not mutate anything and I do not mix String with GString.

Community
  • 1
  • 1
Michal Kordas
  • 10,475
  • 7
  • 58
  • 103
  • http://stackoverflow.com/questions/31713359/why-are-there-different-behaviors-for-the-ways-of-addressing-gstring-keys-in-map – tim_yates Aug 25 '16 at 10:46
  • http://stackoverflow.com/questions/9682206/groovy-different-results-on-using-equals-and-on-a-gstringimpl – tim_yates Aug 25 '16 at 10:47
  • 1
    Tim, these questions do not provide answer for me - they are about mutability or mixing `String` with `GString`. In my code I do not mutate or mix anything. – Michal Kordas Aug 25 '16 at 11:14
  • @tim_yates, I have to agree with Michal Kordas . The cited answers really do not have bearing on this problem. – BalRog Aug 25 '16 at 18:22
  • @Michal Kordas, I think you have found a Groovy bug. As I traced through this code in the debugger I found that the expression ```map[gString]``` invoked the category method ```DefaultGroovyMethods.getAt(Object,String)``` (with the ```GString``` coerced to ```String```, of course), rather than the expected (at least by me) ```DefaultGroovyMethods.getAt(getAt(Map,K)```. I don't know how the Groovy runtime engine came to make such a decision, but it seems to me that it is the wrong decision. – BalRog Aug 25 '16 at 19:02
  • Oddly enough, if you replace ```map[gString]``` with ```map.getAt(gString)```, then it still fails the same way. However, if you replace it with ```DefaultGroovyMethods.getAt(map, gString)```, then you get what seems to me to be the correct behavior. – BalRog Aug 25 '16 at 19:19

2 Answers2

10

tl;dr: You seem to have discovered a bug in Groovy's runtime argument overloading evaluation.

Answer:

map[gString] is evaluated as map.getAt(gString) at runtime straightforwardly via Groovy's operator overloading mechanism. So far, so good, but now is where everything starts to go awry. The Java LinkedHashMap class does not have a getAt method anywhere in it's type hierarchy, so Groovy must use dynamically associated mixin methods instead (Actually that statement is sort of reversed. Groovy uses mixin methods before using the declared methods in the class hierarchy.)

So, to make a long story short, Groovy resolves map.getAt(gString) to use the category method DefaultGroovyMethods.getAt(). Easy-peasy, right? Except that this method has a large number of different argument overloads, several of which might apply, especially when you take Groovy's default argument coercion into account.

Unfortunately, instead of choosing DefaultGroovyMethods.getAt(Map<K,V>,K), which would seem to be a perfect match, Groovy chooses DefaultGroovyMethods.getAt(Object,String), which coerces the GString key argument into a String. Since the actual key is in fact a GString, the method ultimately fails to find the value.

To me the real killer is that if the argument overload resolution is performed directly from code (instead of after the operator resolution and the category method selection), then Groovy makes the right overload choice! That is to say, if you replace this expression:

map[gString]

with this expression:

DefaultGroovyMethods.getAt(map,gString)

then the argument overloading is resolved correctly, and the correct value is found and returned.

BalRog
  • 3,216
  • 23
  • 30
  • @roger.glover would you have any insight as to why there is this similar issue with system property values? http://stackoverflow.com/questions/42212368/different-results-when-setting-getting-system-properties-with-gstrings-in-groovy – Dustin Feb 13 '17 at 21:06
  • 1
    Thank you for this in-depth explanation. It explained why a certain cache didn't work for 9 months, unbeknownst to us. ‍♂️ – Stefan Hoth Feb 11 '20 at 08:11
  • In general, it is a bad idea to use unevaluated GStrings as map keys. It's almost never what you really want anyway. – BalRog Feb 11 '20 at 16:20
-3

There's nothing wrong with Groovy. A GString is not a String. It is mutable and as such should never be used as a key in a map (like any other mutable object in Java).

Learn more about this in the docs: http://docs.groovy-lang.org/latest/html/documentation/index.html#_gstring_and_string_hashcodes

melix
  • 1,510
  • 7
  • 6
  • 1
    I've updated question with one more assert - hash code is the same and I'm not mutating this `GString` at all – Michal Kordas Aug 25 '16 at 09:30
  • 1
    moreover, using mutable objects as map keys is perfectly fine as long as the object is not mutated after being inserted into the map. – james turner Nov 03 '16 at 18:20