I'll answer in more detail later, but it's a LinkedHashMap.get that's being called.
A. On Tue, Aug 22, 2017 at 4:34 PM, Jochen Theodorou <[email protected]> wrote: > On 22.08.2017 00:53, Andrew Bayer wrote: > >> Hey all - >> >> I'm working on an issue in Jenkins' Groovy sandboxing logic - >> https://issues.jenkins-ci.org/browse/JENKINS-46327. The problem is that >> 'map."some${variable}"' seems to be acting as if the GStringImpl was the >> key, rather than the String it should coerce to. I've got a feeling this is >> due to a flaw in our sandbox's method dispatch code somewhere, so I'm >> trying to figure out how Groovy is deciding to coerce normally. And I can't >> tell where that would be. =) Anyone got any pointers? >> > > it is legal to call get(String) with a String, but the transformation > happens during the method call by the runtime. Method dispatch in the meta > class is deciding about what method is to be taken. It is different for > static compilation of course. > > Now if you have a list of all the get-methods that are available I can > easily tell you which method will be called and why. So for example if you > have get(String), get(Object) and get(CharSequence) a call to that method > with a GString will call the CharSequence method, because that is an > interface GString is implementing. If that methods would be not there it > would have been get(String), because String is seen as more near to GString > than Object for the runtime. Obviously this is not following strictly the > class hierarchy > > bye Jochen > >
