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
